Здравствуйте, дорогие друзья.

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

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

Обман веб-кэша

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

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

Например, предположим, что у вас есть конечная точка “setting.php”, которая возвращает имя пользователя, адрес электронной почты, адрес и номер телефона. Доступ может быть предоставлен нескольким пользователям setting.php и каждый ответ будет отличаться, поскольку ответ зависит от пользователя в данный момент вы вошли в систему, поэтому не имеет смысла использовать кэширование на этой странице. Также по соображениям безопасности вы, вероятно, не хотите, чтобы ваше приложение кэшировало страницы с конфиденциальной информацией.

Как вы можете видеть на изображении выше, в строке 15 есть заголовок “cache-control”, для которого установлено значение “no-cache”. Это указывает серверу кэширования не кэшировать эту страницу. Однако иногда сервер кэширования все равно принимает решение о кэшировании страницы. Обычно это происходит, когда сервер кэширования настроен на кэширование любой страницы, заканчивающейся определенным расширением (css, jpg, png и т.д.). Кэширующий сервер будет кэшировать все статические страницы независимо от того, что написано в заголовках ответов. Таким образом, если бы мы запросили “example.com/nonexistent.css”, кэширующий сервер кэшировал бы этот ответ независимо от заголовков ответов, поскольку оно настроено таким образом. Далее давайте рассмотрим путаницу путей. Путаница путей возникает, когда приложение загружает одни и те же ресурсы независимо от того, каким является путь. С появлением больших веб-приложений и сложных таблиц маршрутизации появилась путаница путей.

Как вы можете видеть выше, в корневом каталоге есть общий путь к каталогу. Это означает, что любой путь после “/” будет передан в ту же функцию, что и в предыдущем случае, и даст те же результаты.

Оба URL-адреса “example.com” и “example.com/something» будут отправлены в одну и ту же функцию catch_all. Мы просто печатаем путь, но в реальном мире приложение выполнит некоторую задачу и вернет HTML-ответ.

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

Первый метод “параметр пути” используется, когда дополнительные пути, добавленные к запросу, передаются в ту же серверную функцию. Таким образом, “example.com/account.php” — это то же самое, что “example.com/account.php/nonexistent.css” в глазах приложения. Однако сервер кэширования видит “example.com/account.php/nonexistent.css”.

Второй метод “кодирования новой строки” пытается воспользоваться тем фактом, что некоторые прокси-серверы и веб-серверы перестают считывать данные после символа новой строки, а кэширующий сервер — нет. Таким образом, веб-сервер видит “example.com/account.php”, но кэширующий сервер, расположенный перед веб-сайтом, видит “example.com/account.php%0Anonexistent.css”, поэтому он кэширует ответ, потому что они разные.

Третий метод “закодированная точка с запятой” использует тот факт, что некоторые веб-серверы используют точки с запятой(;) в качестве параметров. Однако сервер кэширования может не распознать это значение и обработать запрос как отдельный ресурс. Веб-сайт видит “example.com/account.php” с параметром ”nonexistent.css», но кэширующий сервер видит только “example.com/account.php%3Bnonexistent.css”.

Четвертый метод “encoded pound” использует тот факт, что веб-серверы часто обрабатывают символ pound как идентификатор фрагмента HTML и после этого прекращают разбор URL-адреса. Однако сервер кэширования может не распознать это, поэтому он видит “example.com/account.php%23nonexistent.css ” пока сервер видит “example.com/account.php ”. Последний прием “закодированный вопросительный знак” использует тот факт, что веб-серверы обрабатывают вопросительные знаки(?) как параметры, но сервер кэширования обрабатывает ответ по-другому. Таким образом, сервер кэширования видит “example.com/account.php%3fname=valnonexistent.css”, а веб-сервер видит “example com/account php” example.com/account.php .

Как вы можете догадаться, эти атаки связаны с тем, что веб-сервер интерпретирует запрос одним способом, в то время как кэширующий сервер интерпретирует его по-другому. Если мы сможем заставить приложение одинаково интерпретировать два разных URL-адреса, в то время как сервер кэширования будет интерпретировать их по-разному при кэшировании страницы, существует вероятность обмана веб-кэша. Теперь давайте поработаем с живым приложением. Как показано ниже, при переходе по пути “/users/me” приложение предоставляет нам некоторую личную информацию, такую как адрес электронной почты, имя и номер телефона.

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

● example.com/nonexistent.css

● example.com/%0Anonexistent.css

● example.com/%3Bnonexistent.css

● example.com/%23nonexistent.css

● example.com/%3fname=valnonexistent.css

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

Теперь любой, кто просмотрит этот URL-адрес, увидит информацию о целевом пользователе, что приведет к утечке конфиденциальной личной информации.

Резюме

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

На этом все. Всем хорошего дня!

Цикл статей по Bug Bounty.