0
Vander
Команда форума
- 10.11.2019
- 495
- 1 158
Приветствую уважаемую аудиторию форума Protey!
Продолжаем разбирать способы возникновения уязвимостей, отравляющих веб-кеш, и рассматриваем практические примеры, предыдущие статьи цикла можно найти тут:
Использование отравления веб-кэша для использования уязвимостей при обработке файлов 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 кэшем также может быть использована с использованием методов отравления веб-кэша. Однако на практике этот вектор является относительно редким по сравнению с отравлением кэша на основе заголовков. При наличии уязвимостей, связанных с отравлением кэша на основе файлов cookie, они, как правило, быстро обнаруживаются и устраняются, поскольку легитимные пользователи случайно отравляют кэш.
Практический пример:
Отравление веб-кэша неключевым файлом cookie
Эта лаборатория уязвима для отравления веб-кэша, потому что куки не включены в ключевые параметры кэша. Пользователь посещает домашнюю страницу примерно раз в минуту. Чтобы решить эту задачу, отравите кэш ответом, который запускает alert (1) в браузере посетителя.
- Запустив Burp, загрузите домашнюю страницу сайта.
- В Burp перейдите к «Proxy» > «HTTP history» и изучите сгенерированные вами запросы и ответы. Обратите внимание, что первый полученный вами ответ устанавливает cookie fehost = prod-cache-01.
- Перезагрузите домашнюю страницу и обратите внимание, что значение из cookie-файла fehost отражено в объекте JavaScript с двойными кавычками в ответе.
- Отправьте этот запрос в Burp Repeater и добавьте параметр cache buster.
- Измените значение cookie на произвольную строку и повторите запрос. Убедитесь, что эта строка отражена в ответе.
- Поместите подходящую полезную нагрузку XSS в cookie-файл fehost, например: fehost = SomeString "-alert (1) -" SomeString
- Повторяйте запрос, пока не увидите полезную нагрузку в ответе и попадание X-Cache: в заголовки.
- Обновите страницу и подтвердите срабатывание alert ().
- Вернитесь к Burp Repeater, удалите cache buster и повторите запрос, чтобы сохранить кеш в ядре, пока жертва не посетит сайт, и лаборатория не будет решена.
Некоторые сайты уязвимы для простых эксплойтов отравления кеша, как показано выше. Однако для других требуются более сложные атаки, и они становятся уязвимыми только тогда, когда злоумышленник может создать запрос, который манипулирует несколькими неключевыми параметрами.
Например, скажем, веб-сайт требует безопасного общения с использованием 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Практический пример:
Отравление веб-кэша несколькими заголовками
В этой лабораторной работе содержится уязвимость, приводящая к отравлению веб-кэша, которая может использоваться только при использовании нескольких заголовков для создания вредоносного запроса. Пользователь посещает домашнюю страницу примерно раз в минуту. Чтобы решить эту задачу, отравите кэш ответом, который запускает оповещение (document.cookie) в браузере посетителя.
Примечание: эта лаборатория поддерживает заголовки X-Forwarded-Host и X-Forwarded-Scheme.
- Запустив Burp, загрузите домашнюю страницу сайта.
- Перейдите в «Proxy» > «HTTP history» и изучите сгенерированные вами запросы и ответы. Найдите запрос GET для файла JavaScript /resources/js/tracking.js и отправьте его в Burp Repeater.
- Добавьте параметр cache buster и заголовок X-Forwarded-Host с произвольным именем хоста, например example.com. Обратите внимание, что это не оказывает никакого влияния на ответ.
- Удалите заголовок X-Forwarded-Host и добавьте вместо него заголовок X-Forwarded-Scheme. Обратите внимание, что если вы включите любое значение, кроме HTTPS, вы получите ответ 302. Заголовок Location показывает, что вы перенаправлены на тот же URL-адрес, который вы запрашивали, но с использованием https://.
- Добавьте в запрос заголовок X-Forwarded-Host: example.com, но также сохраните X-Forwarded-Scheme: nothttps. Отправьте этот запрос и обратите внимание, что Location header 302 redirect теперь указывает на https://example.com/.
- Перейдите на сервер эксплойтов и измените имя файла в соответствии с путем, используемым уязвимым ответом: /resources/js/tracking.js
- В теле payload введите alert(document.cookie) и сохраните эксплойт.
- Вернитесь к запросу в Burp Repeater и установите заголовок X-Forwarded-Host следующим образом, не забывая ввести свой собственный идентификатор сервера эксплойтов: X-Forwarded-Host: your-exploit-server-id.web-security-academy.net
- Убедитесь, что в заголовке X-Forwarded-Scheme установлено любое другое значение, кроме HTTPS.
- Отправляйте запрос, пока в ответе не отобразится URL вашего сервера эксплойтов, а X-Cache: попадет в заголовки.
- Чтобы проверить правильность кэширования ответа, щелкните правой кнопкой мыши запрос в Burp, выберите «Copy URL» и загрузите этот URL в браузере. Если кэш был успешно отравлен, вы увидите скрипт, содержащий вашу полезную нагрузку, alert (document.cookie). Обратите внимание, что alert () на самом деле не будет выполняться здесь.
- Вернитесь в «Burp Repeater», удалите cache buster и повторяйте запрос, пока вы снова не отравите кэш.
- Чтобы смоделировать жертву, перезагрузите домашнюю страницу в вашем браузере и убедитесь, что оповещение () срабатывает.
- Повторяйте запрос на сохранение кэша отравленным, пока жертва не зайдет на сайт и задание не будет решено.
Спасибо за внимание, материал подготовлен специально для форума protey.net
Последнее редактирование: