Web Cache Deception

Уязвимость Web Cache Deception позволяет атакующему заставить веб-кэш сохранять чувствительный динамический контент. Она вызвана расхождениями в том, как сервер кэша и исходный (origin) сервер обрабатывают запросы.

В атаке Web Cache Deception атакующий убеждает жертву посетить вредоносный URL, побуждая браузер жертвы выполнить неоднозначный запрос к чувствительному контенту. Кэш неверно интерпретирует его как запрос к статическому ресурсу и сохраняет ответ. Затем атакующий может запросить тот же URL, чтобы получить кэшированный ответ, получив несанкционированный доступ к приватной информации.

wcd-image-1.png

Note

Важно отличать Web Cache Deception от Web Cache Poisoning. Хотя обе техники эксплуатируют механизмы кэширования, они делают это по-разному:

• Web Cache Poisoning манипулирует ключами кэша, чтобы внедрить вредоносный контент в кэшируемый ответ, который затем раздается другим пользователям.

• Web Cache Deception эксплуатирует правила кэширования, чтобы обманом заставить кэш сохранять чувствительный или приватный контент, к которому затем может получить доступ атакующий.

Для более подробной информации об Web Cache Deception см. тему Web-Cache Poisoning.

PortSwigger research

PortSwigger разработал несколько преднамеренно уязвимых лабораторных работ, с помощью которых вы можете безопасно практиковать изученные приемы на реалистичных целях. Многие из этих лабораторных работ основаны на оригинальном исследовании, впервые представленном на Black Hat USA 2024.

Подробности см. в сопровождающем докладе (whitepaper): Gotta Cache 'em all: bending the rules of web cache exploitation.

Веб-кэш

Веб-кэш — это система, которая находится между исходным сервером и пользователем. Когда клиент запрашивает статический ресурс, запрос сначала направляется в кэш. Если кэш не содержит копии ресурса (это называется cache miss), запрос перенаправляется на исходный сервер, который обрабатывает и отвечает на него. Затем ответ отправляется в кэш перед тем, как попасть к пользователю. Кэш использует заранее настроенный набор правил, чтобы определить, сохранять ли ответ.

Когда в будущем поступает запрос на тот же статический ресурс, кэш напрямую отдает пользователю сохраненную копию ответа (это называется cache hit).

caching.svg

Кэширование стало распространенной и важной частью доставки веб-контента, особенно с широким использованием CDN, которые применяют кэширование для хранения копий контента на распределенных серверах по всему миру. CDN ускоряют доставку, отдавая контент с сервера, ближайшего к пользователю, уменьшая время загрузки за счет сокращения расстояния, которое должны пройти данные.

Ключи кэша

Когда кэш получает HTTP-запрос, он должен решить, есть ли кэшированный ответ, который можно отдать напрямую, или нужно ли переслать запрос на исходный сервер. Кэш принимает это решение, создавая «ключ кэша» из элементов HTTP-запроса. Обычно это включает путь URL и параметры запроса, но также может включать множество других элементов, таких как заголовки и тип содержимого.

Если ключ кэша входящего запроса совпадает с ключом предыдущего запроса, кэш считает их эквивалентными и отдает копию кэшированного ответа.

Note

Как манипулировать ключами кэша для внедрения вредоносного контента в кэш, см. тему Отравление веб-кэша (web cache poisoning).

Правила кэширования

Правила кэширования определяют, что можно кэшировать и на какой срок. Часто правила настраиваются для хранения статических ресурсов, которые, как правило, редко меняются и повторно используются на нескольких страницах. Динамический контент не кэшируется, так как он чаще содержит конфиденциальную информацию, что гарантирует получение пользователями актуальных данных напрямую с сервера.

Атаки Web Cache Deception эксплуатируют то, как применяются правила кэширования, поэтому важно знать о разных типах правил, особенно основанных на заданных строках в пути URL запроса. Например:

• Правила для статических расширений файлов — соответствуют расширению запрашиваемого ресурса, например .css для таблиц стилей или .js для файлов JavaScript.

• Правила для статических каталогов — соответствуют всем путям URL, начинающимся с определенного префикса. Часто используются для целевых директорий, содержащих только статические ресурсы, например /static или /assets.

• Правила для имен файлов — соответствуют конкретным именам файлов, нацеленным на файлы, которые универсально требуются для работы веб-сайтов и редко меняются, такие как robots.txt и favicon.ico.

Кэши также могут реализовывать пользовательские правила на основе других критериев, таких как параметры URL или динамический анализ.

Построение атаки Web Cache Deception

В общем случае построение базовой атаки Web Cache Deception включает следующие шаги:

1. Определите целевой эндпоинт, который возвращает динамический ответ с чувствительной информацией. Изучайте ответы в Burp, поскольку часть чувствительной информации может быть не видна на отрендеренной странице. Старайтесь выбирать эндпоинты, поддерживающие методы GET, HEAD или OPTIONS, поскольку запросы, изменяющие состояние исходного сервера, обычно не кэшируются.

2. Найдите расхождение в том, как кэш и исходный сервер разбирают путь URL. Это может быть расхождение в том, как они:

   • сопоставляют URL с ресурсами;

   • обрабатывают символы-разделители;

   • нормализуют пути.

3. Сформируйте вредоносный URL, который использует это расхождение, чтобы обманом заставить кэш сохранить динамический ответ. Когда жертва переходит по URL, ее ответ сохраняется в кэше. С помощью Burp вы можете затем отправить запрос к тому же URL, чтобы получить кэшированный ответ с данными жертвы. Избегайте выполнения этого напрямую в браузере, так как некоторые приложения перенаправляют пользователей без сессии или инвалидируют локальные данные, что может скрыть уязвимость.

Использование «cache buster»

При тестировании расхождений и составлении необходимых для эксплуатации Web Cache Deception нужно убедиться, что у каждого отправленного запроса разный ключ кэша. Иначе вам могут возвращаться кэшированные ответы, что повлияет на результаты тестов.

Поскольку путь URL и любые параметры запроса обычно включаются в ключ кэша, вы можете изменить ключ, добавив к пути строку запроса и меняя ее при каждом отправлении запроса. Автоматизируйте это с помощью расширения Param Miner. Для этого после установки расширения щелкните верхнее меню Param miner > Settings, затем выберите Add dynamic cachebuster. Теперь Burp добавляет уникальную строку запроса к каждому вашему запросу. Добавленные строки запроса можно просматривать на вкладке Logger.

Обнаружение кэшированных ответов

Во время тестирования крайне важно уметь определять кэшированные ответы. Для этого смотрите на заголовки ответа и время ответа.

Разные заголовки ответа могут указывать на кэширование. Например:

• Заголовок X-Cache дает информацию о том, был ли ответ отдан из кэша. Типичные значения:

  • X-Cache: hit — ответ был отдан из кэша.

  • X-Cache: miss — в кэше не было ответа для ключа запроса, поэтому он был получен с исходного сервера. В большинстве случаев ответ затем кэшируется. Чтобы подтвердить это, отправьте запрос снова и посмотрите, изменится ли значение на hit.

  • X-Cache: dynamic — исходный сервер динамически сгенерировал контент. Обычно это означает, что ответ не подходит для кэширования.

  • X-Cache: refresh — кэшированный контент устарел и требовал обновления или повторной валидации.

• Заголовок Cache-Control может включать директиву, указывающую на кэширование, например public с max-age больше 0. Учтите, что это только говорит о кэшируемости ресурса. Это не всегда признак фактического кэширования, так как кэш иногда может переопределять этот заголовок.

Если вы замечаете большую разницу во времени ответа на один и тот же запрос, это также может указывать на то, что более быстрый ответ отдан из кэша.

Эксплуатация правил кэширования по статическим расширениям

Правила кэширования часто нацелены на статические ресурсы, сопоставляя распространенные расширения файлов, такие как .css или .js. Это поведение по умолчанию в большинстве CDN.

Если есть расхождения в том, как кэш и исходный сервер сопоставляют путь URL с ресурсами или используют разделители, атакующий может сформировать запрос к динамическому ресурсу со статическим расширением, которое игнорируется исходным сервером, но учитывается кэшем.

Расхождения в сопоставлении путей

Сопоставление пути URL — это процесс привязки путей URL к ресурсам на сервере, таким как файлы, скрипты или выполнение команд. Разные фреймворки и технологии используют различные стили сопоставления. Два распространенных стиля — традиционное сопоставление URL и REST-ориентированное сопоставление URL.

Традиционное сопоставление URL представляет прямой путь к ресурсу, расположенному в файловой системе. Типичный пример: http://example.com/path/in/filesystem/resource.html

• http://example.com указывает на сервер.

• /path/in/filesystem/ представляет путь каталога в файловой системе сервера.

• resource.html — конкретный запрашиваемый файл.

В отличие от этого, REST-стиль URL напрямую не соответствует физической файловой структуре. Он абстрагирует пути к файлам в логические части API: http://example.com/path/resource/param1/param2

• http://example.com указывает на сервер.

• /path/resource/ — эндпоинт, представляющий ресурс.

• param1 и param2 — параметры пути, используемые сервером для обработки запроса.

Расхождения в том, как кэш и исходный сервер сопоставляют путь URL с ресурсами, могут приводить к уязвимостям Web Cache Deception. Рассмотрим следующий пример: http://example.com/user/123/profile/wcd.css

• Исходный сервер, использующий REST-сопоставление URL, может интерпретировать это как запрос к эндпоинту /user/123/profile и вернуть информацию профиля пользователя 123, игнорируя wcd.css как незначимый параметр.

• Кэш, использующий традиционное сопоставление URL, может рассматривать это как запрос к файлу wcd.css, расположенному в каталоге /profile внутри /user/123. Он интерпретирует путь URL как /user/123/profile/wcd.css. Если кэш настроен на хранение ответов для запросов, путь которых оканчивается на .css, он закэширует и будет отдавать информацию профиля как будто это CSS-файл.

Эксплуатация расхождений в сопоставлении путей

Чтобы проверить, как исходный сервер сопоставляет путь URL с ресурсами, добавьте произвольный сегмент пути к URL целевого эндпоинта. Если ответ все еще содержит те же чувствительные данные, что и базовый ответ, это указывает на то, что исходный сервер абстрагирует путь URL и игнорирует добавленный сегмент. Например, это так, если изменение /api/orders/123 на /api/orders/123/foo все еще возвращает информацию о заказе.

Чтобы проверить, как кэш сопоставляет путь URL с ресурсами, вам нужно модифицировать путь, пытаясь совпасть с правилом кэша, добавив статическое расширение. Например, измените /api/orders/123/foo на /api/orders/123/foo.js. Если ответ кэшируется, это указывает:

• что кэш интерпретирует полный путь URL со статическим расширением;

• что существует правило кэша для хранения ответов на запросы, оканчивающиеся на .js.

У кэшей могут быть правила на основе конкретных статических расширений. Попробуйте набор расширений, включая .css, .ico и .exe.

Затем вы можете сформировать URL, который возвращает динамический ответ, сохраняемый в кэше. Обратите внимание, что эта атака ограничена конкретным эндпоинтом, который вы тестировали, поскольку исходный сервер часто имеет разные правила абстракции для разных эндпоинтов.

Note

Burp Scanner автоматически обнаруживает уязвимости web cache deception, вызванные расхождениями в сопоставлении путей, в ходе аудита. Вы также можете использовать BApp Web Cache Deception Scanner для выявления неправильно настроенных веб-кэшей.

LAB

Exploiting path mapping for web cache deception

Расхождения в использовании разделителей (delimiters)

Разделители задают границы между различными элементами в URL. Использование символов и строк как разделителей в целом стандартизовано. Например, ? обычно используется для отделения пути URL от строки запроса. Однако, поскольку RFC по URI достаточно лоялен, между разными фреймворками или технологиями все же возникают различия.

Расхождения в том, как кэш и исходный сервер используют символы и строки как разделители, могут приводить к уязвимостям Web Cache Deception. Рассмотрим пример /profile;foo.css:

• Фреймворк Java Spring использует символ ; для добавления параметров, известных как матричные переменные. Поэтому исходный сервер на Java Spring интерпретирует ; как разделитель. Он усекает путь после /profile и возвращает информацию профиля.

• Большинство других фреймворков не используют ; как разделитель. Следовательно, кэш, который не использует Java Spring, вероятно, интерпретирует ; и все, что следует за ним, как часть пути. Если у кэша есть правило хранения ответов для запросов, оканчивающихся на .css, он может закэшировать и отдавать информацию профиля как будто это CSS-файл.

То же верно и для других символов, которые используются непоследовательно между фреймворками или технологиями. Рассмотрим эти запросы к исходному серверу на Ruby on Rails, который использует . как разделитель для указания формата ответа:

• /profile — этот запрос обрабатывается formatter’ом HTML по умолчанию, который возвращает информацию профиля пользователя.

• /profile.css — этот запрос распознается как CSS-расширение. CSS-formatter отсутствует, поэтому запрос не принимается и возвращается ошибка.

• /profile.ico — этот запрос использует расширение .ico, которое не распознается Ruby on Rails. Formatter по умолчанию для HTML обрабатывает запрос и возвращает информацию профиля пользователя. В этой ситуации, если кэш настроен хранить ответы для запросов, оканчивающихся на .ico, он будет кэшировать и отдавать информацию профиля как будто это статический файл.

Иногда в качестве разделителей могут использоваться и закодированные символы. Например, рассмотрим запрос /profile%00foo.js:

• Сервер OpenLiteSpeed использует закодированный нулевой символ %00 как разделитель. Поэтому исходный сервер на OpenLiteSpeed интерпретирует путь как /profile.

• Большинство других фреймворков отвечают ошибкой, если в URL содержится %00. Однако, если кэш использует Akamai или Fastly, он интерпретирует %00 и все последующее как путь.

Эксплуатация расхождений в разделителях

Вы можете воспользоваться расхождением в разделителях, чтобы добавить статическое расширение к пути, которое будет воспринято кэшем, но не исходным сервером. Для этого нужно определить символ, который используется исходным сервером как разделитель, но не используется кэшем.

Сначала найдите символы, используемые исходным сервером как разделители. Начните с добавления произвольной строки к URL целевого эндпоинта. Например, измените /settings/users/list на /settings/users/listaaa. Вы будете использовать этот ответ как ориентир, когда начнете проверять символы-разделители.

Note

Если ответ идентичен исходному, это указывает на то, что запрос перенаправляется. Вам нужно выбрать другой эндпоинт для тестирования.

Далее добавьте возможный разделитель между исходным путем и произвольной строкой, например /settings/users/list;aaa:

• Если ответ идентичен базовому ответу, это указывает на то, что символ ; используется как разделитель и исходный сервер интерпретирует путь как /settings/users/list.

• Если он совпадает с ответом на путь с произвольной строкой, это указывает на то, что ; не используется как разделитель, и исходный сервер интерпретирует путь как /settings/users/list;aaa.

Определив разделители, используемые исходным сервером, проверьте, используются ли они также кэшем. Для этого добавьте статическое расширение в конец пути. Если ответ кэшируется, это указывает:

• что кэш не использует данный разделитель и интерпретирует полный путь URL со статическим расширением;

• что существует правило кэша для хранения ответов на запросы, оканчивающиеся на .js.

Обязательно протестируйте все ASCII-символы и набор распространенных расширений, включая .css, .ico и .exe.

Список потенциальных символов-разделителей в лабораторных работах

!
"
#
$
%
&
'
(
)
*
+
,
-
.
/
:
;
<
=
>
?
@
[
\
]
^
_
`
{
|
}
~
%21
%22
%23
%24
%25
%26
%27
%28
%29
%2A
%2B
%2C
%2D
%2E
%2F
%3A
%3B
%3C
%3D
%3E
%3F
%40
%5B
%5C
%5D
%5E
%5F
%60
%7B
%7C
%7D
%7E

Используйте Burp Intruder, чтобы быстро протестировать эти символы. Чтобы Burp Intruder не кодировал символы-разделители, отключите автоматическое кодирование символов в разделе Payload encoding на боковой панели Payloads.

Затем вы можете составить эксплойт, который срабатывает на правиле кэширования по статическому расширению. Например, рассмотрим полезную нагрузку /settings/users/list;aaa.js. Исходный сервер использует ; как разделитель:

• Кэш интерпретирует путь как: /settings/users/list;aaa.js

• Исходный сервер интерпретирует путь как: /settings/users/list

Исходный сервер возвращает динамическую информацию профиля, которая сохраняется в кэше.

Поскольку разделители, как правило, используются последовательно в пределах одного сервера, эту атаку часто можно применять к многим различным эндпоинтам.

Note

Некоторые символы-разделители могут быть обработаны браузером жертвы до пересылки запроса в кэш. Это означает, что некоторые разделители нельзя использовать в эксплойте. Например, браузеры URL-кодируют такие символы, как {, }, < и >, а # используют для усечения пути.

Если кэш или исходный сервер декодирует эти символы, возможно использовать закодированную версию в эксплойте.

LAB

Exploiting path delimiters for web cache deception

Расхождения в декодировании разделителей

Иногда сайтам требуется передавать в URL данные, содержащие символы со специальным значением внутри URL, такие как разделители. Чтобы эти символы интерпретировались как данные, их обычно кодируют. Однако некоторые парсеры декодируют определенные символы до обработки URL. Если символ-разделитель декодируется, он может быть воспринят как разделитель, что приведет к усечению пути URL.

Различия в том, какие символы-разделители декодируются кэшем и исходным сервером, могут приводить к расхождениям в интерпретации пути URL, даже если оба используют одни и те же символы как разделители. Рассмотрим пример /profile%23wcd.css, где используется URL-кодированный символ #:

• Исходный сервер декодирует %23 в #. Он использует # как разделитель, поэтому интерпретирует путь как /profile и возвращает информацию профиля.

• Кэш также использует # как разделитель, но не декодирует %23. Он интерпретирует путь как /profile%23wcd.css. Если есть правило кэширования для расширения .css, он сохранит ответ.

Кроме того, некоторые серверы кэша могут декодировать URL и затем пересылать запрос с декодированными символами. Другие сначала применяют правила кэширования на основе закодированного URL, затем декодируют URL и пересылают его следующему серверу. Эти различия также могут приводить к расхождениям в том, как кэш и исходный сервер интерпретируют путь URL. Рассмотрим пример /myaccount%3fwcd.css:

• Сервер кэша применяет правила кэширования на основе закодированного пути /myaccount%3fwcd.css и решает сохранить ответ, поскольку есть правило кэширования для расширения .css. Затем он декодирует %3f в ? и пересылает переписанный запрос на исходный сервер.

• Исходный сервер получает запрос /myaccount?wcd.css. Он использует символ ? как разделитель, поэтому интерпретирует путь как /myaccount.

Эксплуатация расхождений в декодировании разделителей

Вы можете эксплуатировать расхождение в декодировании, используя закодированный разделитель, чтобы добавить статическое расширение к пути, которое будет воспринято кэшем, но не исходным сервером.

Используйте ту же методику тестирования, что и при выявлении и эксплуатации расхождений в разделителях, но применяйте набор закодированных символов. Убедитесь, что вы также тестируете закодированные непечатные символы, особенно %00, %0A и %09. Если эти символы декодируются, они также могут усечь путь URL.

Эксплуатация правил кэширования для статических каталогов

Обычная практика — хранить статические ресурсы на веб-серверах в отдельных каталогах. Правила кэширования часто нацелены на эти каталоги, сопоставляя определенные префиксы пути URL, такие как /static, /assets, /scripts или /images. Эти правила также могут быть уязвимы к Web Cache Deception.

Note

Чтобы эксплуатировать правила кэширования статических каталогов, вам нужно понимать основы атак Path Traversal. Подробнее Path Traversal.

Расхождения в нормализации

Нормализация включает преобразование различных представлений путей URL в стандартизованный формат. Иногда это включает декодирование закодированных символов и разрешение dot-сегментов, но это сильно варьируется от парсера к парсеру. Расхождения в том, как кэш и исходный сервер нормализуют URL, могут позволить атакующему составить полезную нагрузку с Path Traversal, которая по-разному интерпретируется каждым парсером. Рассмотрим пример /static/..%2fprofile:

• Исходный сервер, который декодирует символы слэша и разрешает dot-сегменты, нормализует путь до /profile и вернет информацию профиля.

• Кэш, который не разрешает dot-сегменты и не декодирует слэши, интерпретирует путь как /static/..%2fprofile. Если кэш хранит ответы для запросов с префиксом /static, он будет кэшировать и отдавать информацию профиля.

Как показано в примере выше, каждый dot-сегмент в последовательности Path Traversal должен быть закодирован. Иначе браузер жертвы разрешит его до пересылки запроса в кэш. Следовательно, эксплуатируемое расхождение в нормализации требует, чтобы либо кэш, либо исходный сервер декодировал символы в последовательности обхода пути, а также разрешал dot-сегменты.

Обнаружение нормализации на исходном сервере

Чтобы проверить, как исходный сервер нормализует путь URL, отправьте запрос к некэшируемому ресурсу с последовательностью обхода пути и произвольным каталогом в начале пути. Чтобы выбрать некэшируемый ресурс, ищите неидемпотентный метод, например POST. Например, измените /profile на /aaa/..%2fprofile:

• Если ответ соответствует базовому ответу и возвращает информацию профиля, это указывает на то, что путь интерпретирован как /profile. Исходный сервер декодирует слэш и разрешает dot-сегмент.

• Если ответ не соответствует базовому, например возвращается сообщение об ошибке 404, это указывает на то, что путь интерпретирован как /aaa/..%2fprofile. Исходный сервер либо не декодирует слэш, либо не разрешает dot-сегмент.

Note

При тестировании нормализации начните с кодирования только второго слэша в dot-сегменте. Это важно, потому что некоторые CDN сопоставляют слэш, следующий за префиксом статического каталога.

Вы также можете попробовать кодировать всю последовательность обхода пути или кодировать точку вместо слэша. Это иногда влияет на то, декодирует ли парсер последовательность.

Обнаружение нормализации на сервере кэша

Есть несколько способов проверить, как кэш нормализует путь. Сначала определите потенциальные статические каталоги. В Proxy > HTTP history найдите запросы с распространенными префиксами статических каталогов и кэшированными ответами. Сфокусируйтесь на статических ресурсах, установив фильтр истории HTTP так, чтобы показывались только сообщения с ответами 2xx и типами MIME для скриптов, изображений и CSS.

Затем выберите запрос с кэшированным ответом и повторно отправьте его с последовательностью обхода пути и произвольным каталогом в начале статического пути. Выберите запрос с ответом, содержащим признаки кэширования. Например, /aaa/..%2fassets/js/stockCheck.js:

• Если ответ больше не кэшируется, это указывает на то, что кэш не нормализует путь перед сопоставлением с эндпоинтом. Это показывает, что существует правило кэша на основе префикса /assets.

• Если ответ все еще кэшируется, это может указывать на то, что кэш нормализовал путь до /assets/js/stockCheck.js.

Вы также можете добавить последовательность обхода пути после префикса каталога. Например, измените /assets/js/stockCheck.js на /assets/..%2fjs/stockCheck.js:

• Если ответ больше не кэшируется, это указывает на то, что кэш декодирует слэш и разрешает dot-сегмент при нормализации, интерпретируя путь как /js/stockCheck.js. Это показывает, что существует правило кэша на основе префикса /assets.

• Если ответ все еще кэшируется, это может указывать на то, что кэш не декодировал слэш и не разрешил dot-сегмент, интерпретируя путь как /assets/..%2fjs/stockCheck.js.

Обратите внимание, что в обоих случаях ответ может кэшироваться из-за другого правила кэширования, например основанного на расширении файла. Чтобы подтвердить, что правило основано на статическом каталоге, замените путь после префикса каталога произвольной строкой. Например, /assets/aaa. Если ответ все еще кэшируется, это подтверждает правило кэширования на основе префикса /assets. Учтите, что если ответ не кажется кэшированным, это не обязательно исключает правило кэширования статического каталога, так как иногда ответы 404 не кэшируются.

Note

Возможно, вы не сможете однозначно определить, декодирует ли кэш dot-сегменты и декодирует ли путь URL, не попытавшись провести эксплуатацию.

Эксплуатация нормализации на исходном сервере

Если исходный сервер разрешает закодированные dot-сегменты, а кэш — нет, вы можете попытаться эксплуатировать расхождение, составив полезную нагрузку следующей структуры:

/<static-directory-prefix>/..%2f<dynamic-path>

Например, рассмотрим полезную нагрузку /assets/..%2fprofile:

• Кэш интерпретирует путь как: /assets/..%2fprofile

• Исходный сервер интерпретирует путь как: /profile Исходный сервер возвращает динамическую информацию профиля, которая сохраняется в кэше.

LAB

Exploiting origin server normalization for web cache deception

Эксплуатация нормализации на сервере кэша

Если сервер кэша разрешает закодированные dot-сегменты, а исходный сервер — нет, вы можете попытаться эксплуатировать расхождение, составив полезную нагрузку следующей структуры:

/<dynamic-path>%2f%2e%2e%2f<static-directory-prefix>

Note

При эксплуатации нормализации на сервере кэша кодируйте все символы в последовательности Path Traversal. Использование закодированных символов помогает избежать неожиданного поведения при использовании разделителей, и нет необходимости иметь нескодированный слэш после префикса статического каталога, поскольку кэш обработает декодирование.

В этой ситуации одного обхода пути недостаточно для эксплуатации. Например, рассмотрим, как кэш и исходный сервер интерпретируют полезную нагрузку /profile%2f%2e%2e%2fstatic:

• Кэш интерпретирует путь как: /static

• Исходный сервер интерпретирует путь как: /profile%2f%2e%2e%2fstatic

Исходный сервер, вероятно, вернет сообщение об ошибке вместо информации профиля. Чтобы эксплуатировать это расхождение, вам также нужно определить разделитель, который используется исходным сервером, но не кэшем. Проверьте возможные разделители, добавив их к полезной нагрузке после динамического пути:

• Если исходный сервер использует разделитель, он усечет путь URL и вернет динамическую информацию.

• Если кэш не использует разделитель, он разрешит путь и закэширует ответ.

Например, рассмотрим полезную нагрузку /profile;%2f%2e%2e%2fstatic. Исходный сервер использует ; как разделитель:

• Кэш интерпретирует путь как: /static

• Исходный сервер интерпретирует путь как: /profile

Исходный сервер возвращает динамическую информацию профиля, которая сохраняется в кэше. Таким образом, вы можете использовать эту полезную нагрузку для эксплуатации.

LAB

Exploiting cache server normalization for web cache deception

Эксплуатация правил кэширования по именам файлов

Определенные файлы, такие как robots.txt, index.html и favicon.ico, часто встречаются на веб-серверах. Их часто кэшируют из-за редких изменений. Правила кэширования нацеливаются на эти файлы, сопоставляя точную строку имени файла.

Чтобы определить, существует ли правило кэширования по имени файла, отправьте GET-запрос для возможного файла и проверьте, кэшируется ли ответ.

Обнаружение расхождений в нормализации

Чтобы проверить, как исходный сервер нормализует путь URL, используйте тот же метод, что и для правил кэширования статических каталогов. Подробнее Обнаружение нормализации на исходном сервере.

Чтобы проверить, как кэш нормализует путь URL, отправьте запрос с последовательностью обхода пути и произвольным каталогом перед именем файла. Например, /profile%2f%2e%2e%2findex.html:

• Если ответ кэшируется, это указывает на то, что кэш нормализует путь до /index.html.

• Если ответ не кэшируется, это указывает на то, что кэш не декодирует слэш и не разрешает dot-сегмент, интерпретируя путь как /profile%2f%2e%2e%2findex.html.

Эксплуатация расхождений в нормализации

Поскольку ответ кэшируется только если запрос совпадает с точным именем файла, вы можете эксплуатировать лишь то расхождение, при котором сервер кэша разрешает закодированные dot-сегменты, а исходный сервер — нет. Используйте тот же метод, что и для правил кэширования статических каталогов — просто замените префикс статического каталога именем файла. Подробнее Эксплуатация нормализации на исходном сервере.

LAB

Exploiting exact-match cache rules for web cache deception

Предотвращение уязвимостей Web Cache Deception

Вы можете предпринять ряд шагов для предотвращения уязвимостей Web Cache Deception:

• Всегда используйте заголовки Cache-Control для пометки динамических ресурсов, установив директивы no-store и private.

• Настройте параметры вашей CDN так, чтобы правила кэширования не переопределяли заголовок Cache-Control.

• Активируйте любую защиту вашей CDN от атак Web Cache Deception. Многие CDN позволяют установить правило кэширования, которое проверяет, что заголовок Content-Type ответа соответствует расширению файла в URL запроса. Например, Cache Deception Armor в Cloudflare.

• Убедитесь, что нет расхождений в том, как исходный сервер и кэш интерпретируют пути URL.