Атака с подделкой межсайтового запроса (CSRF)

Mutt

Professional
Messages
1,058
Reputation
7
Reaction score
565
Points
83
Содержание статьи
  • Что такое CSRF
  • Пример CSRF
  • Методы смягчения CSRF
  • Использование собственных правил для предотвращения атак CSRF

Что такое CSRF
Подделка межсайтовых запросов (CSRF), также известная как XSRF, Sea Surf или Session Riding, представляет собой вектор атаки, который обманом заставляет веб-браузер выполнить нежелательное действие в приложении, в которое вошел пользователь.

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

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

csrf-cross-site-request-forgery.png.webp


Пример CSRF
Прежде чем совершить нападение, злоумышленник обычно изучает приложение, чтобы сделать поддельный запрос как можно более легитимным.

Например, типичный запрос GET для банковского перевода на 100 долларов может выглядеть так:
Code:
GET http://netbank.com/transfer.do?acct=PersonB&amount=$100 HTTP/1.1

Хакер может изменить этот сценарий так это приводит к передаче $ 100 на свой счет. Теперь вредоносный запрос может выглядеть так:
Code:
GET http://netbank.com/transfer.do?acct=AttackerA&amount=$100 HTTP/1.1

Плохой субъект может встроить запрос в невинно выглядящую гиперссылку:
Code:
<a href="http://netbank.com/transfer.do?acct=AttackerA&amount=$100">Подробнее!</a>

Затем он может разослать гиперссылку по электронной почте большому количеству клиентов банка. Те, кто нажмет на ссылку, войдя в свой банковский счет, непреднамеренно инициируют перевод 100 долларов.

Обратите внимание, что если веб-сайт банка использует только POST-запросы, невозможно создать вредоносные запросы с помощью тега <a> href. Однако атака может быть доставлена в теге <form> с автоматическим выполнением встроенного JavaScript.

Вот так может выглядеть такая форма:
Code:
<body onload="document.forms[0].submit()">
   <form action="http://netbank.com/transfer.do" method="POST">
     <input type="hidden" name="acct" value="AttackerA"/>
     <input type="hidden" name="amount" value="$100"/>
     <input type="submit" value="View my pictures!"/>
   </form>
 </body>

Методы смягчения CSRF
Существует ряд эффективных методов как для предотвращения, так и для смягчения CSRF-атак. С точки зрения пользователя, предотвращение - это вопрос защиты учетных данных для входа и запрета неавторизованным участникам доступа к приложениям.

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

Двойная отправка файлов куки - еще один известный метод блокировки CSRF. Подобно использованию уникальных токенов, случайные токены назначаются как cookie, так и параметру запроса. Затем сервер проверяет соответствие токенов перед предоставлением доступа приложению.

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

Использование собственных правил для предотвращения атак CSRF
Сугубо индивидуальный характер атак CSRF препятствует разработке универсального решения. Однако можно использовать настраиваемые политики безопасности для защиты от возможных сценариев CSRF.

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

Используя IncapRules, вы можете создать политику, которая фильтрует запросы к конфиденциальным страницам и функциям на основе содержимого вашего заголовка реферера HTTP. Это позволяет выполнять запросы из короткого списка безопасных доменов.

Этот метод полностью противостоит аспекту социальной инженерии CSRF-атак. Он предотвращает выполнение злонамеренных запросов за пределами периметра безопасности, независимо от содержимого.

В качестве альтернативы вы можете запустить правило в режиме «Только оповещение», чтобы отслеживать возможные попытки использования уязвимостей, или представить CAPTCHA, которые предупреждают неосторожных пользователей.
 
Top