Подделка межсайтовых запросов – что такое атака CSRF и как ей предотвратить

poddelka mezhsajtovyh zaprosov – chto takoe ataka csrf i kak

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

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

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

Что такое HTTP-запросы и куки-файлы?

HTTP-запрос GET

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

Запрос HTTP POST

Это запрос, который используется для передачи данных на веб-сервер (например, представление веб-форм).

Некоторые запросы GET и POST запускаются автоматически без взаимодействия с пользователем (например, получение предложений поиска или загрузка содержимого изображения с помощью атрибута img src).

Файлы сеанса cookie

Файлы cookie сеанса – это способ обработки состояния HTTP (поскольку оно не обрабатывает состояние первоначально). Веб-сайты используют файлы cookie сеанса (содержащие уникальный идентификатор) для идентификации пользователей и сохранения их сеанса.

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

Злоумышленник может использовать файл cookie, чтобы выдавать себя за пользователя, заставив браузер пользователя выполнить запрос. Если пользователь уже вошел на сайт, файл cookie будет отправлен автоматически вместе с запросом.

Как работает подделка межсайтовых запросов?

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

  • В программе есть действие, которое хочет выполнить злоумышленник – например изменить пароль, перечислить средства и т.д.
  • Нет непредвиденных параметров запроса – злоумышленник может угадать (или знать) все параметры, которые программа ожидает от такого запроса.
  • Действие может быть выполнено с помощью HTTP-запроса(ов), и оно полагается только на файлы cookie, чтобы проверить, поступает ли запрос от пользователя.

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

Атака CSRF может использовать как запрос GET, так и запрос POST (хотя запрос POST более сложный и, следовательно, редкость).

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

Кроме того, подобно XSS (межсайтовый сценарий), CSRF может быть сохраненной уязвимостью. Сохраненный CSRF возникает, когда злоумышленник сохраняет атаку в поле принимаемое HTML, например тег IMG или IFRAME. Это означает, что любой, кто просматривает страницу, может пострадать. Эксплойт может быть замаскирован под обычную ссылку или скрыт в теге изображения.

Например, как обычная ссылка на веб-странице: <a href=“malicious link”>Unsubscribe here</a>

Или как тег изображения: <img src=“malicious link” width=“0” height=“0” border=“0”>

Пример CSRF

Представьте, что ваш банк (bank.com) обрабатывает переводы с помощью запросов GET, которые включают в себя несколько параметров (личность получателя перевода и сумму, которую вы хотите перевести).

Например, если Джим хочет послать своему другу Бобу 10 долларов, запрос может выглядеть так:

http://bank.com/transfer?recipient=Bob&amount=10

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

Теперь злоумышленник может убедить Джима нажать ссылку, которая выглядит так (но была сокращена с помощью сокращения URL-адресов или умело создана гиперссылкой):

http://bank.com/transfer?recipient=Hacker&amount=100000

Поскольку Джим уже вошел в систему, его браузер отправляет его файл cookie с запросом – поэтому его банк считает, что он запрашивает перевод, и он выполняется.

Как остановить атаки CSRF

Внимательно выбирайте свои фреймворки

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

Используйте токены Anti-CSRF

Токены (также известные как шаблоны маркеров синхронизатора) — это защита на стороне сервера, когда сервер предоставляет браузеру пользователя уникальный, случайно сгенерированный маркер и проверяет каждый запрос, чтобы проверить, отправляет ли его браузер назад, прежде чем выполнить запрос.

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

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

Используйте метку SameSite в файлах cookie

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

В сущности, если www.bank.com хочет сделать запрос к www.bank.com/updatepassword, разрешено. Но если www.maliciousdomain.com хочет сделать запрос на www.bank.com/updatepassword, он не может отправить файл cookie сеанса, и поэтому не может осуществить атаку.

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

Углубленно практикуйте защиту

Вы можете реализовать ряд других средств контроля, которые в сочетании с другими мерами могут обеспечить защиту от CSRF.

Например, вот некоторые другие средства защиты, которые можно установить:

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

Привлечь Пользователя к Транзакции

Для конфиденциальных действий, таких как денежные переводы или изменение пароля, требуйте от пользователя действия (например, CAPTCHA, одноразовые токены или повторная аутентификация).

Примеры неработающих мероприятий:

  • Многоэтапные транзакции: Неважно, сколько шагов есть, если злоумышленник может предусмотреть/определить каждый из них.
  • HTTPS: Всегда хорошая идея, но ничего не делает для защиты от CSRF.
  • Перезапись URL: Это не позволит злоумышленникам угадать идентификатор сеанса жертвы во время атаки CSRF, но затем позволит злоумышленнику увидеть его в URL-адресе. Менять один недостаток другим – не очень хорошая идея.
  • Использование секретного файла cookie: Даже секретный файл cookie подается как часть запроса, что означает, что злоумышленник все еще может использовать его.
  • Прием только запросов POST/избегание запросов GET: Поддельные запросы POST все еще можно использовать для выполнения атаки CSRF.

Другие названия CSRF

CSRF также известен как XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery, Hostile Linking, One-Click Attack.

Источники/Дополнительное чтение:

Добавить комментарий

Ваш адрес email не будет опубликован.