[PortSwigger] Web cache poisoning

본 글은 보안 학습 및 연구 목적으로 작성되었으며, 허가되지 않은 시스템에 대한 공격 또는 테스트는 관련 법령에 따라 처벌될 수 있습니다. 학습 목적으로 작성된 본 글의 내용을 이용하여 위법 행위를 할 경우, 그로 인해 발생하는 모든 책임은 해당 행위를 수행한 당사자에게 있으며, 본 글의 작성자는 이에 대해 책임을 지지 않습니다.

해당 글은 PortSwigger Web Security Academy 실습 내용을 정리한것입니다.

 

 

About Web Cache

웹 캐시는 백엔드의 부하(load)를 줄이기 위해 등장한 개념이다. 같은 요청에 대해서 다음 요청은 응답 복사본을 제공하는 방식이다. 요청이 같음은 cache key라는 개념을 사용하는데, cache key는 요청에서 사전 정의된 요소 하위 집합이며, 보통 요청 라인과 Host header이다. 이를 제외한 부분은 unkeyed라고 한다. web cache poisoning을 식별하는 것은 다음 절차를 포함한다. web cache poisoning은 악성 페이로드의 영향을 여러 사용자들에게 파급력을 끼칠 수 있는 기법이다.

 

1. unkeyed input을 식별하기: cache key는 같은 요청임을 결정하기 위한 조건이기때문에 공격에 사용한 payload는 unkeyed input이여아 하므로 공격자는 먼저 unkeyed input이 무엇인지 식별해야한다.
2. 응답값에 악성페이로드 반영하기
3. 응답값이 캐시되는지 확인하기

 

Lab: Web cache poisoning with an unkeyed header

 

위 사진을 통해 응답값에서 cache와 관련된 header를 확인할 수 있다. 실제로 변조된 요청값으로 몇번 시도하면서 응답값을 관찰해보면, cache server를 사용하는 것을 유추할 수 있다. 요청값을 수정하면서 어떤 값들이 cache key인지 유추할 수 있다.

 

 

param-miner라는 burpsuite extension을 통해 가능한 header정보를 스캔한다. 이 과정을 통해 unkeyed input의 헤더 후보들을 모은다. 해당 도구를 통해 서버는 X-Forwarded-Host헤더를 사용하는 것을 확인할 수 있다.

 

 

해당 값은 URL자리에 반사되는 것을 확인할 수 있다. zeroone01 query를 넣는 것은 실제 사용자들에게 포이즈닝된 응답값이 가지 않도록 하는 안전장치이다.

 

 

원래 요청에서는 javascript는 원래 서버의 자원을 로드하도록 되어 있다. 

 

 

하지만 해커서버를 마련하여 악성 페이로드(resources/js/tracking.js)로 요청할 수 있도록 구축한 뒤, 해커 서버 URL을 응답값에 캐싱되도록 요청 값을 변조할 수 있다. 이는 요청값이 응답값에 반영되어 XSS를 할 수 있다는 점과 조작된 응답값이 캐싱된다는 점을 악용하는 것이다.

 

 

실제 서버에 접속하면, 포이즈닝이 잘 되는 것을 확인할 수 있다. 이제 /cb?zeroone01 query를 지우고, web cache poisoning을 하면, 대다수의 사용자들이 악성 페이로드(i.e., 경고창)를 실행하게 될 것이다. 아무리 poisoning이 잘 된것을 확인했더라도 실제로 수행하면 위험할 수 있다.

 

 

Lab: Web cache poisoning with an unkeyed cookie

해당 문제는 unkeyed cookie가 XSS를 할 수 있도록 해준다. 나머지는 위 문제와 같다. 

 

 

 

References

https://portswigger.net/web-security/web-cache-poisoning