Отравление веб-кэша

Что такое отравление веб-кэша?

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

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

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

Исследование отравления веб-кэша

Этот метод был впервые популяризирован в нашей исследовательской статье 2018 года «Практическое отравление веб-кэша» и получил дальнейшее развитие в 2020 году во второй исследовательской статье «Запутывание веб-кэша: новые пути к отравлению». Если вам интересно подробное описание того, как мы обнаружили и использовали эти уязвимости в реальных условиях, полные записи доступны на нашей странице исследования.

Как работает веб-кеш?

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

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

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

Ключи кэша

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

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

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

Каковы последствия атаки с отравлением веб-кэша?

Воздействие отравления веб-кэша сильно зависит от двух ключевых факторов:

• Что именно злоумышленник может успешно закэшировать?
  Поскольку зараженный кеш — это скорее средство распространения, чем отдельная атака, воздействие отравления веб-кэша неразрывно связано с тем, насколько опасна внедренная полезная нагрузка. Как и в случае большинства видов атак, отравление веб-кеша также можно использовать в сочетании с другими атаками, чтобы еще больше усилить потенциальное воздействие.
• Объем трафика на затронутой странице
  . Отравленный ответ будет обслуживаться только пользователями, которые посещают затронутую страницу, пока кеш отравлен. В результате влияние может варьироваться от несуществующего до огромного в зависимости от того, популярна ли страница или нет. Например, если злоумышленнику удалось отравить кешированный ответ на главной странице крупного веб-сайта, атака может затронуть тысячи пользователей без какого-либо последующего взаимодействия со стороны злоумышленника.

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

Выявление и оценка неключевых входных данных

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

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

Парам Майнер

К счастью, вы можете автоматизировать процесс определения входных данных без ключа, добавив расширение Param Miner в Burp из магазина BApp. Чтобы использовать Param Miner, вы просто щелкаете правой кнопкой мыши запрос, который хотите исследовать, и нажимаете «Угадать заголовки». Затем Param Miner запускается в фоновом режиме, отправляя запросы, содержащие различные входные данные из обширного встроенного списка заголовков. Если запрос, содержащий один из введенных им входных данных, влияет на ответ, Param Miner регистрирует это в Burp либо на панели «Проблемы», если вы используете Burp Suite Professional , либо на вкладке «Вывод» расширения (« Расширитель” > “Расширения” > “Param Miner” > “Вывод”

Например, на следующем снимке экрана Param Miner обнаружил заголовок без ключа X-Forwarded-Hostна главной странице веб-сайта:

Предостережение. При тестировании неключевых входных данных на действующем веб-сайте существует риск непреднамеренного срабатывания кеша для обслуживания сгенерированных вами ответов реальным пользователям. Поэтому важно убедиться, что все ваши запросы имеют уникальный ключ кеша, чтобы они были доставлены только вам. Для этого можно вручную добавлять блокировщик кеша (например, уникальный параметр) в строку запроса каждый раз, когда вы делаете запрос. В качестве альтернативы, если вы используете Param Miner, есть варианты автоматического добавления очистки кеша к каждому запросу.

Получение вредоносного ответа от внутреннего сервера

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

Получить ответ в кэше

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

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

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

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

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

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

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

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

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

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

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

Вы также должны принять следующие меры предосторожности при реализации кэширования:

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

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