CORS(Cross Origin Resource Sharing) - Access-Control-Allow-Origin : *

서버는 접근을 허용하는 발송처에 대한 설정을 주의하고 Cross-Origin 요청을 모두 허용할 수 있는 “Access-Control-Allow-Origin” 헤더의 값에 “*” 와 같은 패턴은 사용하지 말아야 한다. 또한, 허용하는 도메인을 명확하게 신뢰할 수 있는 사이트에 대해서만 접근을 설정(Access-Control-Allow-Origin : 신뢰할 수 있는 사이트)해야 하며 공격자는 Origin 헤더를 조작하여 요청을 발생시킬 수 있으므로 해당 헤더에만 의존한 접근 제어는 피해야 한다.

공격기법 이해를 위한 배경 기술 CORS를 이용하면 서로 다른 도메인간(웹사이트 서버) 자원 공유를 가능하게 해주며, 이는 서버 설정 중 ‘Access-Control-Allow-Origin : domain’을 통해 설정이 가능하다. 예를 들어 www. foo.com에서 www.other.com에 CORS를 통한 자원을 요청할 경우 www.other.com 서버 설정 은 ‘Access-Control-Allow-Origin : www.foo.com 혹은 *(모든 도메인)’으로 설정이 되어있어야 만 한다. CORS 보안 취약점 예방을 위해서는 신뢰할 수 있는 사이트(서버)에 대해서만 접근을 설정을 해야 한다(Access-Control-Allow-Origin : 신뢰할 수 있는 사이트). 

 

공격 시나리오 
① 공격자(Attacker)는 공격 대상 서버(Target Server)의 CSRF 취약점을 이용하여 희생자의 개 인 정보를 탈취하려고 하지만, 공격 대상 서버는 XSS 및 CSRF에 취약하지 않다. 또한 시도하는 모든 공격이 웹 방화벽에 의해서 차단되어 있는 상황이다. 하지만 공격대상 서버는 특정 웹 서버 (HTML5 Server)와 CORS를 위한 신뢰 관계가 형성되어 있음을 확인했다.

② 공격자는 특정 웹 서버(HTML5 Server)에 악성 스크립트가 담긴 파일을 업로드한다. 그리고 공격 대상 서버에는 특정 웹 서버(HTML5 Server)에 업로드 되어있는 파일을 링크하는 게시글을 업로드한다.

③ 희생자는 공격 대상 서버(Target Server)에 접근하여 로그인을 수행한 후 공격자가 ②에서 업로드했던 게시물의 링크를 클릭한다.(물론 해당 링크는 클릭을 유도하는 내용을 담고 있다.) 사용자의 웹브라우저 탭은 특정 웹 서버(HTML5 Server)에 업로드된 악성 스크립트를 가져온 후 실행하게 된다.

④ 악성 스크립트에 노출된 희생자의 웹브라우저는 자신의 개인정보를 공격자에게 전송하 게 된다. 실제 CSRF를 통한 A사용자의 개인정보 탈취 트래픽을 발생시킨 것은 B서버이며, A서버와 (Access-Control-Allow-Origin : www.B.com)으로 신뢰관계를 맺고 있기에 이 공격이 가능하다.

3) 대응방안 『 CORS를 이용한 사용자 개인정보 탈취』시나리오는 공격 대상 사이트의 파일 업로드 취약점을 이용하는 것으로 시작된다. 때문에 웹 서버의 파일 업로드 취약점에 대한 대응 조치를 한다면 공 격을 완화할 수 있다. 그리고 서버는 Cross-Origin 요청을 모두 허용할 수 있는 “Access-ControlAllow-Origin : *” 과 같은 설정을 피하는 것이 좋다.