[WARNING] 또야주의

개요 챕터 2에서는 CORS를 어떻게 설정하면 보안에 취약해지는가를 알아보기 위해서, 1) 취약한 설정 확인 방법 2) 대응방안을 알아보도록 한다. 확인 과정 일단 Burp Suite나 ZAP를 통해 패킷을 잡아서 요청 헤더에 Origin이 있으면 조작해보고, 응답 헤더가 어떻게 반환되는지 확인하는 것이 기본적인 확인 방법이다. (앞으로 작성할 취약한 CORS를 확인하는 모든 유형에 대해) 유형 (1) 설명 CORS 관련 골치아픈 오류를 회피하기 위해, 1) 응답 Access-Control-Allow-Origin 헤더(이하 ACAO 헤더)를 요청 Origin 그대로 응답하도록 설정하고, 2) Access-Control-Allow-Credentials 헤더(이하 ACAC 헤더)를 True로 응답하도록 개발..

개발자가 CORS 정책을 잘못 설정하는 경우 XSS, CSRF 등의 보안 위협이 존재할 가능성이 있다고 하였다. 취약한 CORS 구성을 알아보기 전, 자격증명(Credential)이 전달되는 경우의 CORS 요청에 대해 어떻게 처리해야 하는지 간략히 짚고 넘어간다. Credentialed Request Credential 정보로 취급되는 것 정확히 Credentialed Request로 취급되는 것은 아래 두 가지 경우다. 🤍 쿠키를 포함한 요청 🤍 헤더에 Authorization 항목이 포함된 요청 이전 글인 1-2에서 XHR 객체를 통해 Cross-origin 요청을 하는 코드를 살펴보았다. var httpRequest = new XMLHttpRequest(); var url = "https://ap..

단순 요청인 Simple Request와 프리플라이트 요청이라 불리는 Preflighted Request는 무슨 차이가 있을까? Pre- 접두사가 붙은 것을 보아 미리 뭔가를 더 하겠다는 느낌을 받는다. 단순 요청과 프리플라이트 요청에 차이를 둔 이유와 보안적으로는 어떤 부분이 다른지의 관점 위주로, 이번에는 간단하게 비교해서 정리한다. 가정 http://www.example.com에서 http://api.example.com으로 Ajax GET 요청을 통해 데이터를 받아온다. 🔊 Simple Request Request Response GET /data HTTP/1.1 Host: api.example.com Origin: http://www.example.com HTTP/1.1 200 OK Access..

동작 원리 - 응답 헤더 설정 상세 Cross-site Origin 요청에서는 헤더에 'Origin: protocol://domain:port'이 서버로 전송된다. Same Origin이라도 GET, HEAD 요청을 제외한 메서드는 Origin 헤더가 추가되며, mode 설정에 따라 요청에 사용 가능한 헤더가 제한될 수 있다. 즉 Same Origin이어도 CORS 요청으로 취급될 수 있어 유의해야 한다. So, what the spec means there is: The Origin header is sent in all cross-origin requests, but it’s also always sent for all POST, PUT, PATCH, and DELETE requests — even ..

동작 원리 (1) - 기본 동작하게 만드는 것은 간단히 다음과 같이 헤더를 추가하는 방식으로 하는데, 요청 헤더를 통해 Origin에 대한 정보를 데이터를 받을 서버로 보내면, 데이터를 줄 서버에서 Origin을 검증하여 브라우저가 권한을 확인하게 한다. 동작 원리 (2)에 조금 더 자세한 내용이 있다. 단, MDN에 의하면 요청 헤더인 Origin은 프로그래밍 방식으로 변경할 수 없다. (즉 소스코드에 의해 Origin 요청 헤더를 추가하거나 제외할 수 없다.) A forbidden header name is the name of any HTTP header that cannot be modified programmatically; 그러므로 아래에 나올 코드(요청 단)가 아닌 서버에서 CORS를 활성화..