[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)를 사용하여 **세계에서 가장 고급** 커뮤니티 도구를 활용한 **워크플로우를 쉽게 구축하고 자동화**하세요.\
캐시 독려은 클라이언트 측 캐시를 조작하여 클라이언트가 예상치 못한, 부분적인 또는 공격자의 통제 하에 있는 리소스를 로드하도록 강제하는 것을 목표로 합니다. 영향의 정도는 영향을 받는 페이지의 인기에 따라 달라지며, 오염된 캐시 기간 동안 페이지를 방문하는 사용자에게 오염된 응답이 전달됩니다.
일반적으로 응답이 **캐시에 저장**된 경우 **그렇다는 것을 나타내는 헤더**가 있습니다. 이 게시물에서 주의를 기울여야 할 헤더를 확인할 수 있습니다: [**HTTP 캐시 헤더**](../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
응답이 캐시에 저장되고 있다고 생각한다면 **잘못된 헤더로 요청을 보내어**, **상태 코드 400**으로 응답해야 합니다. 그런 다음 요청을 정상적으로 액세스하고 **응답이 400 상태 코드인지** 확인하면 취약점을 알 수 있습니다 (심지어 DoS를 수행할 수도 있습니다).\
[**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943)를 사용하여 페이지의 응답을 변경할 수 있는 **매개변수 및 헤더를 무차별 대입**할 수 있습니다. 예를 들어 페이지가 클라이언트가 스크립트를 로드하도록 하는 `X-Forwarded-For` 헤더를 사용할 수 있습니다:
식별된 매개변수/헤더를 확인하여 어떻게 **검열**되고 있는지, 그리고 어디에서 **반영**되거나 헤더로부터 응답에 어떤 영향을 미치는지 확인하십시오. 그것을 어떻게 남용할 수 있을까요 (XSS를 수행하거나 제어할 수 있는 JS 코드를 로드할 수 있을까요? DoS를 수행할 수 있을까요?...)
남용할 수 있는 **페이지**, 어떤 **매개변수/헤더**를 사용해야 하는지, 그리고 어떻게 **남용**해야 하는지를 식별한 후 페이지를 캐시해야 합니다. 캐시에 들어갈 자원에 따라 시간이 걸릴 수 있으며, 몇 초 동안 시도해야 할 수도 있습니다.\
응답의 헤더인 **`X-Cache`**는 요청이 캐시되지 않았을 때 값이 **`miss`**일 수 있고, 캐시될 때 값이 **`hit`**일 수 있어 매우 유용할 수 있습니다.\
또 다른 흥미로운 헤더는 **`Cache-Control`**입니다. 자원이 캐시되는지 여부와 자원이 다시 캐시될 다음 시간을 알 수 있습니다: `Cache-Control: public, max-age=1800`\
또 다른 흥미로운 헤더는 **`Vary`**입니다. 이 헤더는 일반적으로 키가 없는 경우에도 캐시 키의 일부로 처리되는 **추가 헤더**를 나타내는 데 자주 사용됩니다. 따라서 사용자가 대상이 되는 피해자의 `User-Agent`를 알고 있다면 해당 특정 `User-Agent`를 사용하는 사용자들을 위해 캐시를 오염시킬 수 있습니다.\
캐시와 관련된 또 다른 헤더는 **`Age`**입니다. 이것은 프록시 캐시에 있는 객체의 시간을 초 단위로 정의합니다.
요청을 캐시할 때 사용하는 헤더에 **주의**하십시오. 일부 헤더는 **키로 사용될 수 있으므로** 예기치 않게 사용될 수 있으며 **피해자는 동일한 헤더를 사용해야** 할 수 있습니다. 항상 **다른 브라우저**로 캐시 오염을 **테스트**하여 작동 여부를 확인하십시오.
### 경로 이동을 사용한 캐시 위조로 API 키 도용 <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
[**이 설명**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)은 `/share/*`와 일치하는 모든 것이 Cloudflare가 URL을 정규화하지 않고 캐시에 저장되기 때문에 `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`와 같은 URL로 OpenAI API 키를 도용할 수 있었던 방법을 설명합니다. 이는 요청이 웹 서버에 도달했을 때 수행되었습니다.
### 여러 헤더를 사용하여 웹 캐시 위조 취약점 악용 <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
가끔은 **여러 키가 없는 입력을 악용**하여 캐시를 남용해야 할 수 있습니다. 예를 들어, `X-Forwarded-Host`를 당신이 제어하는 도메인으로 설정하고 `X-Forwarded-Scheme`를 `http`로 설정하면 **Open redirect**를 찾을 수 있습니다. **만약****서버**가 모든 **HTTP** 요청을 **HTTPS**로 **전달**하고 리디렉트를 위해 헤더 `X-Forwarded-Scheme`을 도메인 이름으로 사용한다면, 리디렉트할 페이지를 제어할 수 있습니다.
만약 응답의 **`Vary`** 헤더가 **`User-Agent`**를 나타내지만 **`X-Host`** 헤더가 **도메인 이름을 JS 리소스로 로드하는 데 사용**된다는 것을 발견했다면, 피해자의 User-Agent를 유출하고 해당 사용자 에이전트를 사용하여 캐시를 오염시키는 방법을 찾아야 합니다:
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)를 사용하여 세계에서 가장 **고급** 커뮤니티 도구를 활용한 **워크플로우를 쉽게 구축** 및 **자동화**하세요.\
ATS는 URL 내의 단편을 제거하지 않고 전달하고 호스트, 경로 및 쿼리만 사용하여 캐시 키를 생성했습니다(단편은 무시). 따라서 요청 `/#/../?r=javascript:alert(1)`이 백엔드로 `/#/../?r=javascript:alert(1)`로 전송되었고 캐시 키에는 페이로드이 아닌 호스트, 경로 및 쿼리만 포함되었습니다.
GitLab은 정적 콘텐츠를 저장하기 위해 GCP 버킷을 사용했습니다. **GCP 버킷**은 **헤더 `x-http-method-override`**를 지원했습니다. 따라서 헤더 `x-http-method-override: HEAD`를 보내고 캐시를 독려하여 빈 응답 본문을 반환할 수 있었습니다. 또한 메서드 `PURGE`를 지원할 수도 있었습니다.
Ruby on Rails 애플리케이션에서는 Rack 미들웨어가 자주 사용됩니다. Rack 코드의 목적은 **`x-forwarded-scheme`** 헤더의 값을 가져와 요청의 체계로 설정하는 것입니다. 헤더 `x-forwarded-scheme: http`가 전송되면 동일한 위치로 301 리디렉션이 발생하여 해당 리소스에 대한 서비스 거부(DoS)가 발생할 수 있습니다. 또한 애플리케이션은 `X-forwarded-host` 헤더를 인식하고 사용자를 지정된 호스트로 리디렉션할 수 있습니다. 이 동작은 공격자의 서버에서 JavaScript 파일을로드하게 할 수 있어 보안 위험을 초래할 수 있습니다.
Cloudflare는 이전에 403 응답을 캐시했습니다. 잘못된 인증 헤더로 S3 또는 Azure Storage Blobs에 액세스하려고 시도하면 캐시된 403 응답이 발생했습니다. Cloudflare는 403 응답을 더 이상 캐시하지 않지만 이 동작은 다른 프록시 서비스에서 여전히 발생할 수 있습니다.
캐시는 캐시 키에 특정 GET 매개변수를 포함시킵니다. 예를 들어 Fastly의 Varnish는 요청에서 `size` 매개변수를 캐시했습니다. 그러나 URL 인코딩된 버전의 매개변수(예: `siz%65`)가 잘못된 값과 함께 전송되면 캐시 키가 올바른 `size` 매개변수를 사용하여 구성됩니다. 그러나 백엔드는 URL 인코딩된 매개변수의 값을 처리합니다. 두 번째 `size` 매개변수를 URL 인코딩하면 캐시에서는 무시되지만 백엔드에서는 사용됩니다. 이 매개변수에 0 값을 할당하면 캐시 가능한 400 Bad Request 오류가 발생합니다.
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230)은 헤더 이름에 허용되는 문자를 지정합니다. 지정된 **tchar** 범위 외의 문자를 포함하는 헤더는 이상적으로 400 Bad Request 응답을 트리거해야 합니다. 실제로 서버는 항상 이 표준을 준수하지는 않습니다. Akamai는 `cache-control` 헤더가 없는 한 잘못된 문자를 포함하는 헤더를 전달하고 400 오류를 캐시합니다. `\`와 같은 잘못된 문자가 포함된 헤더를 보내면 캐시 가능한 400 Bad Request 오류가 발생하는 취약한 패턴이 식별되었습니다.
먼저 `.css`, `.js`, `.png` 등과 같은 **확장자**는 일반적으로 **캐시에 저장**되도록 **구성**됩니다. 따라서 `www.example.com/profile.php/nonexistent.js`에 액세스하면 캐시가 응답을 저장할 가능성이 높습니다. 왜냐하면 `.js` **확장자**를 볼 수 있기 때문입니다. 그러나, **응용 프로그램**이 _www.example.com/profile.php_에 저장된 **민감한** 사용자 콘텐츠를 **재생**하는 경우, 다른 사용자의 콘텐츠를 **도난**할 수 있습니다.
매우 명확한 예시는 다음 글에서 찾을 수 있습니다: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
이 예시에서는 _http://www.example.com/home.php/non-existent.css_와 같이 존재하지 않는 페이지를 로드하면 _http://www.example.com/home.php_의 내용(**사용자의 민감한 정보와 함께**)이 반환되고 캐시 서버가 결과를 저장합니다.\
그런 다음 **공격자**는 자신의 브라우저에서 _http://www.example.com/home.php/non-existent.css_에 액세스하여 이전에 액세스한 사용자의 **기밀 정보**를 관찰할 수 있습니다.
**캐시 프록시**는 파일을 **콘텐츠 유형**이 아닌 파일의 **확장자**에 따라 캐시해야 합니다. 예를 들어 _http://www.example.com/home.php/non-existent.css_의 경우 `text/html` 콘텐츠 유형이 아닌 `text/css` 미메 유형(확장자 `.css`에 대한 예상)을 가질 것입니다.
[HTTP 요청 스머글링을 악용한 캐시 속임수 공격](http-request-smuggling/#using-http-request-smuggling-to-perform-web-cache-deception) 수행 방법에 대해 알아보세요.
[**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks)를 사용하여 세계에서 가장 **고급** 커뮤니티 도구를 활용한 **워크플로우를 쉽게 구축** 및 **자동화**하세요.\
