유튜브에 올라온 Black Hack 컨퍼런스 영상을 보던 중 어썸한 기법을 찾아서 정리 겸 남깁니다. 제 글이 부족하기도 하고 참고링크에 있는 유튜브 영상에 잘 설명되어 있으니, 공부 용도로 보시는 이 글을 분들은 유튜브 영상을 보는 걸 추천합니다. 웹알못이 작성한 글이니 틀린 내용을 발견하시면 지적 부탁드립니다.
Background
1. Front-End server란?
현재 서비스 중인 많은 웹서버는 Front-End와 Back-End 구조로 이루어져 있습니다. Front-End 서버는 유저(브라우저)와 Back-End 서버 사이에서 이 둘의 연결을 이어주는 서버를 말합니다. Front-End 서버는 두가지 용도로 사용됩니다. 이를 간략하게 설명하면 다음과 같습니다.
- load balancer : 한 서버에 많은 트래픽이 몰릴 경우, 서버 디바이스에 과부화가 걸릴 가능성이 큽니다. 따라서 Front-End서버가 실제 서버 앞에서 과하게 몰린 트래픽을 여러 대의 서버 디바이스로 적절하게 배분해줍니다.
- reverse proxy : 유저와 Back-End 서버 사이에서 유저의 요청을 제어하거나, rewrite하는 등의 역할을 합니다. Back-End의 성능에 도움이 되기도 합니다.
2. Web cache란?
웹 페이지는 크게 정적 페이지와 동적 페이지로 나눌 수 있습니다. 동적 페이지는 유저가 전송하는 파라미터에 의해 유저에게 전달되는 reponse가 달라지는 반면 정적페이지는 늘 같은 reponse를 보냅니다. 간단하게 생각해서, test.php와 test.css에 요청을 보내는 경우를 생각해봅시다. test.php는 유저의 GET, POST, Header, Cookie 등을 받아서 처리한 후 그 파라미터들에 따라 다른 respone을 전달할 것입니다. 반면 test.css는 유저가 어떠한 파라미터를 보내도 무시하고 매번 같은 reponse을 전달합니다. 매번 response가 달라지는 test.php의 경우 응답값을 caching하기 어렵지만 매번 같은 값을 reponse하는 test.css 페이지에 대한 요청은 caching이 쉽습니다. 따라서 다 그런건 아니지만, 대부분 정적인 페이지에 대해서 cache를 사용하는 경우가 많은 것으로 보입니다.(cache-key 등을 사용하여 동적인 페이지에 대해서도 cache를 사용할 수 있습니다. 추후 정확한 동향을 확인하면 수정하겠습니다.)
이제 Front-End와 Back-End로 이루어진 서버에서 속도 개선을 위해 Front-End에 Cache를 도입하는 경우를 생각해봅시다. 이러한 환경에서 어느 유저가 test.css에 접근했습니다. 그 경우 요청은 아래와 같이 처리됩니다.
이제 Front-End 서버에서는 test.css의 reponse 값인 css text를 자신의 메모리에 저장합니다. 그리고 다른 유저가 다시 test.css에 대한 요청을 할 경우 자신의 메모리에 있는 test.css의 reponse 값인 css text를 유저에게 전달합니다. 이러한 방식을 통해 Back-End 서버에 대한 부하를 줄일 수 있습니다. 또한 유저도 더 빠르게 응답을 받을 수 있음으로, 서버와 유저 모두에게 이득입니다.
wikipedia에 따르면 Web Cache를 지원하는 프로그램은 다음과 같습니다. 웹알못인 저에게도 친숙한 이름이 많이 있습니다. Nginx, 아파치, 마이크로소프트 등등.
Web cache deception attack
1. Web cache deception attack이란?
Web cache deception attack이 무엇인지 설명하기 전에, 우선 왜 Web caching이 보안적으로 문제가 없는지 생각해봅시다. 우리가 사용하는 웹페이지에는 많은 정보들이 들어있습니다. 관리자 모드의 대시보드, 카드정보, 기타 개인정보 등. 하지만 이러한 정보들은 대게 동적 페이지의 결과물로써 reponse됩니다. 정적 페이지에서는 이러한 민간한 정보들이 없습니다. 따라서 개발자는 이러한 민감한 페이지에 대해서는 cache를 사용하지 않아야 합니다. 주로 정적인 페이지와 같이 많이 변하지 않고, 중요한 정보가 없는 페이지에 대해서만 cache를 사용합니다.
Web cache deception attack은 Front-End 서버가 cache를 사용하지 말아야 할 페이지에 대하여 cache를 저장하게 하는 공격기법입니다. 예를 들어서 다음과 같은 요청을 생각해봅시다.
GET /admin.php /HTTP 1.1
관리자가 admin.php에 접근했으니 웹페이지에는 관리자 용 대시보드가 나올 것입니다. 거기에는 민감한 정보가 많이 있겠죠. 당연히 이런 경우 Front-End 서버는 이 요청에 대한 reponse를 caching하지 않습니다. 이것은 동적 페이지라 caching하는 것이 큰 의미가 없을 뿐더러 보안적으로 위험하니까요.
하지만 아래와 같은 요청이 들어온다면 어떨까요.
GET /admin.php/nonexistcss.css /HTTP 1.1
본래는 /admin.php/nonexistcss.css는 없는 파일이기 때문에 404 에러를 반환해야 합니다. 하지만 가끔 이러한 요청에 대해 404 에러를 반환하는 대신 admin.php로 요청이 들어온 것과 같이 취급을 하는 페이지가 있습니다. (이 경우 web cache deception attack 뿐만 아니라 relative path overwite 공격에도 취약할 수 있으니 바람직하지 않은 코딩 방식이라 생각합니다.) 만약 Back-end 서버가 404 에러를 띄우는 대신 admin.php의 reponse 값을 Front-End 서버에 전달한다고 생각해봅시다. 그 경우 Front-End 서버는 유저가 전달한 요청의 확장자가 css이기 때문에, Back-End 서버가 전달한 reponse값이 정적 페이지에 들어온 요청의 reponse 값이라고 생각할 것입니다. 따라서 Front-End 서버는 /admin.php/nonexistcss.css에 들어온 요청에 대한 response 값을 caching합니다. caching된 값에는 admin.php에 존재하는 민간한 정보들이 다수 있고요.
그후 관리자가 아닌 다른 이용자가 /admin.php/nonexistcss.css에 다시 접근할 경우 Front-End 서버는 caching된 reponse를 관리자가 아닌 사용자에게 전달합니다. 그러면 관리자가 아닌 사용자는 admin.php의 reponse를 확인할 수 있게 됩니다.
2. Web cache deception attack의 성공 조건
- Front-End 서버의 Web cache 기준이 파일의 확장자이어야 합니다. 이때 HTTP header와 상관없이 caching되어야 합니다.
- page.php/nonexistcss.css에 요청한 reponse값이 page.php이어야 합니다.
- 희생자가 공격자에 의해 조작된 URL에 접속해야 합니다.
3. Web cache deception attack을 방지하는 방법
- HTTP caching headers이 허가해줄 때만 caching이 이루어져야 합니다.
- 모든 static 파일들을 특정(디자인된) 폴더에만 업로드해야 합니다.
- caching의 기준이 확장자가 아니라, 파일의 type이어야 합니다.
- page.php/nonexistcss.css와 같은 페이지에 접근했을 때 302혹은 404를 return해야 합니다.
Another attack vector for web cache
web cache를 이용한 다른 공격으로 web cache poisoning이 있습니다. Web cache deception과 반대 방법으로 공격하는 기법입니다. 따로 정리하려다가 한글로 잘 정리된 글이 있어서 첨부합니다.
https://www.hahwul.com/2018/12/web-cache-poisoning-attack-with-header-xss.html
참고자료
https://www.youtube.com/watch?v=mroq9eHFOIU
https://ko.wikipedia.org/wiki/%EC%9B%B9_%EC%BA%90%EC%8B%9C
ps. portswigger에서 만든 Web cache deception 취약점 감지 툴이 있다. 아직 사용해보지는 않았는데 HTTP request smuggler는 아주 만족해서, 이것도 기대해도 좋을 것 같다.
https://portswigger.net/bappstore/7c1ca94a61474d9e897d307c858d52f0
'WEB' 카테고리의 다른 글
| Relative Path Overwrite (0) | 2020.09.15 |
|---|---|
| Redpwn CTF 2020 / post-it-notes (0) | 2020.06.23 |
| SOP, CORS, CSP (0) | 2020.04.21 |
| javascript proto pollution (3) | 2020.03.05 |
