Cross-site request forgery (CSRF)

Я исследую веб‑безопасность и делюсь практическими разбориками уязвимостей: от CSRF и XXE до Server‑Side XSS, race conditions и обходов CSP. Пишу чек‑листы атак и защиты, редкие кейсы из практики и мысли о мышлении пентестера. Только прикладной AppSec, понятные примеры и то, что реально встречается в проде. Учимся охотиться, пока на нас не охотятся.

csrfwebcookie

🌟Cross-site request forgery - это веб-уязвимость, которая позволяет атакующему побудить пользователя выполнить действия, которые он не собирался выполнять.

🌟Тип: Web, Client-Side.

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

Эксплуатация уязвимости возможна, если соблюдены три основных условия:

  • 6️⃣Релевантное действие. Действие, которое атакующий заставляет сделать жертву, должно иметь смысл и выполнять конкретную вещь. Это может быть, например, модификация данных или какое-то привилегированное действие. Заставить пользователя открыть картинку или произвести выход из аккаунта с трудом можно отнести к CSRF и почти ни одно bb такую уязвимость не примет.
  • 2️⃣Авторизация при помощи Cookie (и наличие у жертвы активной сессии). В противном случае эксплуатация будет невозможна: если у пользователя нет активной сессии, то и действий от его аккаунта сделать не получится; если для авторизации используется токены из localStorage - у нас нет ни единого механизма заставить этот токен отправиться автоматически при отправке запроса (а для эксплуатации требуется именно автоматическая отправка браузером подобных данных). Тут нас спасет только наличие XSS, но тогда и смысла в CSRF будет немного.
  • 3️⃣Отсутствие непредсказуемых параметров запроса. Тут все просто - если приложение выполнит наш запрос успешно, только если он содержит какое-то непредсказуемое значение, то мы должны включить это значение в запрос, который мы хотим, чтобы был выполнен от лица жертвы. А так как мы не имеем возможности его угадать, то и включить в запрос мы его не сможем.

🌟Если все условия соблюдены, то атаку можно провести каким-то таким кодом:

<html>
    <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@evil-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>
    

Я бы выделил два основных вида CSRF:

  • 🔗Классическая - выполняется через отправку формы (как в примере выше). При наличии уязвимости, сработает в 100% случаев, но мы не будем иметь возможности увидеть ответ на наш запрос.
  • 🔗Скриптовая - выполняется при помощи AJAX или подобных запросов. Здесь мы сможем видеть ответ на запрос, но заставить такую штуку работать сильно (прям сильно) труднее, так как в дело вступает SOP. (Если для вас это незнакомый термин - когда-нибудь позже я сделаю пост с объяснением)

Читайте так же