👨‍💻 Уязвимые фрагменты кода

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

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

Ссылка на GitHub

#code #web

​​📓 Отравляем кэш и получаем Stored XSS в Drupal

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

Самый простой способ узнать, включено ли кэширование - найти заголовок x-drupal-cache в ответе. Таким образом, вы даете уникальный ключ (конечная точка + параметры) в запросе, и в ответ вы получаете заголовок x-drupal-cache: MISS, но если вы снова делаете запрос с тем же ключом и получаете заголовок x-drupal-cache: HIT в ответе, то кэширование включено. Чтобы узнать больше о том, как работает кэширование и его эксплуатация, прочитайте статью от Portswigger.

После того, как вы узнали, что кэширование включено, один из способов, который можно использовать - это отравление кэша полезной нагрузкой для XSS. Но для этого нужно найти HTTP заголовок, который отражается в ответе. Поскольку Drupal, как и любой другой PHP-фреймворк, иногда поддерживает заголовки X-Original-URL и X-Rewrite-URL, можно попробовать ввести эти заголовки в запрос. Если это не сработает, попробуйте брутфорс заголовков.

Для этого можно использовать Param Miner в Burp Suite, который будет перебирать основные заголовки. На изображении ниже вы можете видеть, как был найден заголовок под названием style, который отражался в ответе и был уязвим для XSS.

Ответ с полезной нагрузкой кэшируется для вышеуказанного уникального запроса. Теперь, когда кто-то посещает адрес:

https://www.redacted.com/? q=admin&liec4897=1

отравленный ответ будет отображаться друпалом, в результате чего выполнится Stored XSS.

#web #cache #drupal