아인스트라세의 SW 블로그

https://medium.com/@sasaxxx777/cors-misconfiguration-leading-to-private-information-disclosure-9ebcbd4740d9

본 포스팅은 위 블로그 글의 번역본입니다.

----------------------------------------------------------------------------------------

이번 글에서는 CORS에 관하여 다루어볼 예정이다.

일단 이 사이트를 private.com이라고 해보자.

이것 저것 좀 시도해본 뒤, 이 사이트의 서브도메인을 찾았는데 이거를 xyz.private.com이라고 부르겠다.

그리고 나서 burp suite로 크롤링이랑 파라메터 digging을 시도했고, origin 헤더랑 같이 요청이 날아갔다.

origin 헤더는 이 요청이 어느 도메인에서 시작되었는지를 나타내는 HTTP 헤더이고, path information은 갖지 않는다. 즉 xyz.private.com/index.php 에서 요청을 보냈다면 /index.php 부분의 값은 무시하고 domian 부분만 해당한다는 뜻.

Origin 헤더는 Access-Control-Allow-Origin 헤더에 의해 accept되었고, Access-Control-Allow-Credentials 헤더가 true로 값이 설정되었다.

Access-Control-Allow-Origin 헤더는, 해당 Origin에서 온 요청이 Accept될 것인지 아닌지를 알려주는데, xyz.private.com이 값으로 있으므로, 해당 URL의 Origin에서 시작된 요청은 Accept된다는 뜻이다. Origin 구분없이 Accept될 것이라면 *라고 쓰여있을 것이다.

Access-Control-Allow-Credentials라는 HTTP 헤더는 응답 헤더인데, credential이 포함된 요청을 보냈을 때, 응답 값을 브라우저가 프론트엔드 자바스크립트한테 요청할 지 안할지를 정해주는 그런 헤더라고 한다.

이 현상을 보고, 저자는 서버가 어떻게 origin header를 처리하는지를 조사를 했다.

그리고 원래 메인 도메인으로 요청을 보냈고, 서버는 이에 대하여 accept 했다.

그래서 private.com에서 점을 지우고 보냈는데, 서버가 또다시 accpet을 해 주었다. 서버는 도메인 이름과 com이 있는지만 체크하고, 그 사이에는 무엇이 있든간에 무시하는 것 같았다. 그래서 private와 com사이에 1을 넣어서 보내보았다.

그리고 똑같이 accept가 응답이 돌아왔다.

그래서 privatescom.000webhostapp.com이라는 주소로 하나 도메인을 만들었고, 이를 이용해서 POC 코드를 작성해 보았다.

그리고 만든 도메인에서 응답을 받을 수 있었고, 유저 정보를 훔칠 수 있었다.