Burp Suite. Подробнее о CSRF - атаках

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

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

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

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

<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">

Предотвращение атак CSRF

Самый надежный способ защиты от атак CSRF - включить CSRF token в соответствующие запросы. Токен должен быть: 

• Непредсказуемо с высокой энтропией, как и для токенов сессий в целом.
• Привязан к сеансу пользователя.
• Строго проверяется в каждом случае перед выполнением соответствующего действия.

Дополнительная защита, которая частично эффективна против CSRF и может использоваться в сочетании с токенами CSRF, - это файлы cookie SameSite. SameSite - это расширение файлов cookie HTTP 2016 года, предназначенное для предотвращения подделки межсайтовых запросов (CSRF). Первоначально его дизайн представлял из себя дополнительную функцию, которую можно использовать, добавив новое свойство SameSite в файлы cookie. У него было два значения, Lax и Strict. При установке значения Lax подразумевается, что куки должны отправляться при серфинге по одному сайту или через GET серфинг на ваш сайт с других сайтов. Значение Strict ограничивало cookie запросами, исходящими только от одного сайта. 

Отсутствие установки какого-либо свойства не накладывает никаких ограничений на то, как cookie может работать в запросах. Операции аутентификации OpenIdConnect (например, вход в систему, выход из системы) и другие функции, которые отправляют POST-запросы с внешнего сайта на сайт, запрашивающий операцию, могут использовать файлы cookie для корреляции и/или защиты CSRF. 

Эти операции должны были бы отказаться от SameSite, не устанавливая свойство вообще, чтобы гарантировать, что эти куки будут отправлены во время их специализированных потоков запросов (specialized request flows).

Распространенные уязвимости CSRF

Наиболее интересные уязвимости CSRF возникают из-за ошибок, допущенных при проверке токенов CSRF.

Исходя из примера из предыдущей статьи, предположим, что приложение теперь включает токен CSRF в запрос на изменение пароля пользователя:

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

csrf=WfF1szMUHhiokx9AHFply5L2xAOfjRkE&email=wiener@normal-user.com

Это должно предотвратить атаки CSRF, поскольку нарушает необходимые условия для уязвимости CSRF: приложение больше не полагается исключительно на файлы cookie для обработки сеанса, а запрос содержит параметр, значение которого злоумышленник не может определить.

Однако существуют различные способы взлома защиты, что означает, что приложение по-прежнему уязвимо для CSRF.

Проверка токена CSRF зависит от метода запроса

Некоторые приложения правильно проверяют токен, когда запрос использует метод POST, но пропускают проверку, когда используется метод GET.

В этой ситуации злоумышленник может переключиться на метод GET, чтобы обойти проверку и выполнить CSRF-атаку:

GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

Лабораторная работа: CSRF, где проверка токена зависит от метода запроса.

Функция изменения адреса электронной почты в этой лабораторной работе уязвима для CSRF. Он пытается заблокировать CSRF-атаки, но применяет защиту только к определенным типам запросов. Чтобы решить эту проблему, используйте сервер эксплойтов для размещения HTML-страницы, которая использует CSRF-атаку для изменения адреса электронной почты посетителя. 

• С вашим браузером, проксирующим трафик через Burp Suite, войдите в свою учетную запись, отправьте запрос «Update email» и найдите полученный запрос в своей истории прокси.

Отправьте запрос в Burp Repeater и обратите внимание, что если вы измените значение параметра csrf, запрос будет отклонен.

Используйте «Изменить метод запроса» в контекстном меню, чтобы преобразовать его в запрос GET, и обратите внимание, что токен CSRF больше не проверяется.

Если вы используете Burp Suite Professional, щелкните запрос правой кнопкой мыши и в контекстном меню выберите Engagement tools / Create CSRF PoC. Включите опцию Include auto submit script и нажмите «Regenerate». В качестве альтернативы, если вы используете Burp Suite Community Edition, используйте следующий HTML-шаблон и введите метод запроса, URL-адрес и параметры тела. Вы можете получить URL-адрес запроса, щелкнув правой кнопкой мыши и выбрав «Copy URL».

<form method="$method" action="$url">
     <input type="hidden" name="$param1name" value="$param1value">
</form>
<script>
      document.forms[0].submit();
</script>

• Перейдите на сервер эксплойтов, вставьте HTML-код эксплойта в раздел «Body» и нажмите «Store». 

Чтобы проверить, будет ли эксплойт работать, попробуйте его на себе, нажав «View exploit» и проверив полученный HTTP-запрос и ответ.

Источник

• 🔴 Отказ от ответственности

• 🦋 Слитая информация - @Leakinfo
• 🎭 Наша группа > - Точка входа
• ❤️ Поблагодарить Bitcoin