CORS

CORS

CORS

Croos-origin Resouce Sharing

다른 Domain에 있는 Resource에 접근할 수 있는 Browser Mechanism이다.

많은 Website에서 Subdomain이나 3rd-party site와 상호작용해야 될 일이 많다.

HTTP Header에 인증된 Web Origin과 같은 속성을 사용해서 SOP(Same-origin policy)에 유연성을 줍니다.

SOP

대신 CSRF(Cross-site Request Forgery)와 같은 Cross-domain 공격을 당할 수 있다.

CORS 취약성

ACAO Header 속성

Application에서 허용된 Cross-domain 사이트들을 유지하기 위한 방법

ACAO(Access-Control-Allow-Origin) Header를 이용한다.

Request Header Origin 속성에 허용 사이트를 포함하고,

Respose Header에 Request Header Origin 속성에 있던 사이트를 포함하는 방식이다.

예를 들어,

# Request
GET /sensitive-victim-data HTTP/1.1
Host: vulnerable-website.com
Origin: https://malicious-website.com
Cookie: sessionid=...

# Response
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://malicious-website.com
Access-Control-Allow-Credentials: true
...

Response Header에 Cookie(Access-Control-Allow-Credentials: true)를 포함해서 보낼 수 있다.그러면 해당 Session동안 Cross-domain 허용 사이트가 유지될 것이다.

 

ACAO에 임의 사이트를 넣을 수 있기 때문에 위험하다.

Origin Header null

Web Browser는 아래와 같은 상황에서 Header Origin 속성에 null를 보낼수 있다.

• Cross-origin Redirect
• Request from serialized data
• Request using file: protocol
• Sandboxed cross-origin requests

이렇게 Header Origin 속성에 null값을 이용하면 Whitelist 기반 Domain 관리 정책 위험할 수 있다.

XSS 공격

신뢰를 받은 Origin에서라도 XSS(Cross-site Scripting) 공격을 받을 수 있다.XSS를 통해 상대 Origin에서 중요한 정보를 JavaScript로 읽을 수도 있다.아래와 같이 XSS를 보낼 수 있다.

https://subdomain.vulnerable-website.com/?xss=<script>cors-stuff-here</script>

TLS에 취약한 Croos-Origin

HTTPS가 아닌 HTTP를 사용하는 Origin의 하위 Domain까지 신뢰한다고 가정해본다.

# Request
GET /api/requestApiKey HTTP/1.1
Host: vulnerable-website.com
Origin: http://trusted-subdomain.vulnerable-website.com
Cookie: sessionid=...

# Response
HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://trusted-subdomain.vulnerable-website.com
Access-Control-Allow-Credentials: true

1. 사용자가 HTTP Request를 보낸다.
2. 공격자가 'http://trusted-subdomain.vulnerable-website.com'를 redirection으로 주입한다.
3. 사용자의 Web Browser가 해당 사이트로 redriection 한다.
4. 공격자가 Request를 가로채서 https://vulnerable-website.com를 포함한 조작한 Reponse를 사용자에게 리턴한다.
5. 사용자의 Web Browser가 http://trusted-subdomain.vulnerable-website.com를 포함해서 CORS Request를 보낸다.
6. Application은 Request를 허용한다. 중요 데이터가 Response에 리턴한다.
7. 조작된 Page에서 공격자는 중요한 정보를 읽을 수 있다.

CORS 공격 대처

• Croos-Origin Request를 적절하게 설정 -> Access-Control-Allow-Origin Header에 적절하게 설정
• 검증된 Site만 허용 -> 동적으로 Site 허용하는 것 자제
• WhiteList null 피하기
• Internal Network Wildcard 피하기
• Server에서 뿐만 아니라 Client단에서도 대처