URL 불일치를 통한 캐시 오염

{% hint style="success" %} AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks 지원하기

구독 계획 확인하기!
**💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @hacktricks_live를 팔로우하세요.
HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 팁을 공유하세요.

{% endhint %}

이 문서는 캐시 프록시와 웹 서버 간의 불일치를 악용하여 캐시 오염 공격을 수행하기 위해 제안된 기술의 요약입니다. https://portswigger.net/research/gotta-cache-em-all

{% hint style="info" %} 이 공격의 목표는 캐시 서버가 정적 리소스가 로드되고 있다고 생각하게 만들어 캐시를 저장하는 것입니다. 캐시 서버는 경로의 일부를 캐시 키로 저장하지만 웹 서버는 다른 경로를 해결하여 응답합니다. 웹 서버는 사용자의 민감한 정보, XSS와 같은 악성 페이로드 또는 공격자의 웹사이트에서 JS 파일을 로드하도록 리디렉션하는 동적 페이지를 로드하는 실제 경로를 해결합니다. {% endhint %}

구분자

URL 구분자는 프레임워크와 서버에 따라 다르며, 요청이 라우팅되고 응답이 처리되는 방식에 영향을 미칩니다. 일반적인 원본 구분자는 다음과 같습니다:

세미콜론: Spring에서 행렬 변수를 위해 사용됨 (예: /hello;var=a/world;var1=b;var2=c → /hello/world).
점: Ruby on Rails에서 응답 형식을 지정 (예: /MyAccount.css → /MyAccount)
널 바이트: OpenLiteSpeed에서 경로를 잘라냄 (예: /MyAccount%00aaa → /MyAccount).
새 줄 바이트: Nginx에서 URL 구성 요소를 구분 (예: /users/MyAccount%0aaaa → /account/MyAccount).

이 프로세스를 따라 다른 특정 구분자를 찾을 수 있습니다:

1단계: 캐시할 수 없는 요청을 식별하고 이를 사용하여 잠재적인 구분자가 있는 URL이 어떻게 처리되는지 모니터링합니다.
2단계: 경로에 무작위 접미사를 추가하고 서버의 응답을 비교하여 문자가 구분자로 작동하는지 확인합니다.
3단계: 무작위 접미사 앞에 잠재적인 구분자를 도입하여 응답이 변경되는지 확인하여 구분자 사용을 나타냅니다.

정규화 및 인코딩

목적: 캐시 및 원본 서버의 URL 파서는 엔드포인트 매핑 및 캐시 키를 추출하기 위해 URL을 정규화합니다.
프로세스: 경로 구분자를 식별하고 문자를 디코딩하고 점 세그먼트를 제거하여 경로를 추출하고 정규화합니다.

인코딩

Nginx, Node 및 CloudFront와 같은 다양한 HTTP 서버 및 프록시는 구분자를 다르게 디코딩하여 CDNs 및 원본 서버 간의 불일치를 초래할 수 있습니다. 예를 들어, 웹 서버가 이 변환을 수행하는 경우 /myAccount%3Fparam → /myAccount?param이지만 캐시 서버는 경로 /myAccount%3Fparam을 키로 유지하면 불일치가 발생합니다.

이러한 불일치를 확인하는 방법은 경로를 인코딩 없이 로드한 후 다양한 문자를 URL 인코딩하여 요청을 보내고 인코딩된 경로 응답이 캐시된 응답에서 온 것인지 확인하는 것입니다.

점 세그먼트

점이 포함된 경로 정규화는 캐시 오염 공격에 매우 흥미롭습니다. 예를 들어, /static/../home/index 또는 /aaa..\home/index와 같은 경우, 일부 캐시 서버는 이러한 경로를 키로 캐시할 수 있지만 다른 서버는 경로를 해결하고 /home/index를 캐시 키로 사용할 수 있습니다.
이전과 마찬가지로 이러한 종류의 요청을 보내고 /home/index에 대한 응답이 요청된 경로에서 수집된 응답인지 확인하는 것이 도움이 됩니다.

정적 리소스

여러 캐시 서버는 응답이 정적이라고 식별되면 항상 응답을 캐시합니다. 이는 다음과 같은 이유 때문일 수 있습니다:

확장자: Cloudflare는 다음 확장자를 가진 파일을 항상 캐시합니다: 7z, csv, gif, midi, png, tif, zip, avi, doc, gz, mkv, ppt, tiff, zst, avif, docx, ico, mp3, pptx, ttf, apk, dmg, iso, mp4, ps, webm, bin, ejs, jar, ogg, rar, webp, bmp, eot, jpg, otf, svg, woff, bz2, eps, jpeg, pdf, svgz, woff2, class, exe, js, pict, swf, xls, css, flac, mid, pls, tar, xlsx
구분자와 정적 확장을 사용하여 동적 응답을 캐시하도록 강제할 수 있습니다. 예를 들어 /home$image.png에 대한 요청은 /home$image.png를 캐시하고 원본 서버는 /home으로 응답합니다.
잘 알려진 정적 디렉토리: 다음 디렉토리는 정적 파일을 포함하고 있으므로 그 응답은 캐시되어야 합니다: /static, /assets, /wp-content, /media, /templates, /public, /shared
구분자, 정적 디렉토리 및 점을 사용하여 동적 응답을 캐시하도록 강제할 수 있습니다. 예를 들어 /home/..%2fstatic/something은 /static/something을 캐시하고 응답은 /home이 됩니다.
정적 디렉토리 + 점: /static/..%2Fhome 또는 /static/..%5Chome에 대한 요청은 그대로 캐시될 수 있지만 응답은 /home일 수 있습니다.
정적 파일: /robots.txt, /favicon.ico, /index.html과 같은 특정 파일은 항상 캐시됩니다. 이는 /home/..%2Frobots.txt와 같이 악용될 수 있으며, 캐시는 /robots.txt를 저장하고 원본 서버는 /home에 응답합니다.