CSRF (межсайтовая подделка запросов) — это вид атаки на сайт, которая производится с помощью мошеннического сайта или скрипта, — пишет tproger.ru. — Мошеннический скрипт заставляет браузер пользователя выполнить нежелательное действие на доверенном сайте, на котором пользователь авторизован.
Обычно для этого пользователь должен перейти по мошеннической ссылке (которая может быть изменена с помощью сокращателя ссылок).
Например Джейн, авторизованная на сайте банка, проверяет свою почту. Она может перейти по фишинговой ссылке, которая включает запрос на перевод денег на аккаунт мошенника.
Благодаря тому, что она авторизована на сайте банка, тот обработает запрос на перевод.
Какие HTTP-запросы подвержены CSRF-атаке?
Методы GET, HEAD, OPTIONS и TRACE не подвержены CSRF, потому что предназначены только для получения информации и не изменяют состояние сервера.
Методы POST, PUT, DELETE и PATCH должны быть защищены от CSRF.
Cookies сессии
Cookies-сессии — это способ, которым протокол HTTP отслеживает состояние. Веб-сайты используют cookies для идентификации пользователей и сохранения их данных.
После сохранения cookies, браузер отправляет их на сервер с каждым запросом, чтобы идентифицировать пользователя.
Злоумышленник может использовать cookies, чтобы выдать себя за пользователя, заставив браузер пользователя выполнить запрос.
Если пользователь уже вошел на сайт, cookies будут отправлены автоматически вместе с запросом.
Как работает межсайтовая подделка запросов?
Для того, чтобы злоумышленник осуществил атаку CSRF, нужны определённые условия:
- В приложении есть действие, которое злоумышленник хочет предпринять – например, изменить пароль, перевести средства и так далее.
- Не существует непредсказуемых параметров запроса – злоумышленник может угадать (или знать) все параметры, которые приложение ожидает увидеть из этого типа запроса.
- Действие может быть выполнено с помощью HTTP-запросов, и оно полагается только на файлы cookie, чтобы убедиться, что запрос исходит от пользователя.
CSRF могут быть подвергнуты веб-приложения использующие cookies, браузерную аутентификацию или клиентские сертификаты авторизации. По сути, CSRF подвержены все веб-приложения, которые автоматически добавляют аутентификационные данные пользователя к запросу.
Либо нужно начать с того, что злоумышленник обманом заставит жертву загрузить или отправить информацию в веб-приложение. Это может произойти несколькими способами – например, через фишинговую ссылку.
Эксплойт может быть замаскирован под обычную ссылку или скрыт в теге изображения.
Вот пример атаки через обычную ссылку:
<a href=“вредоносная ссылка”>Unsubscribe here</a>
Или через тэг изображения:
<img src=“вредоносная ссылка” width=“0” height=“0” border=“0”>
Способы защиты от CSRF-атак
Выбор защищённых фреймфорков
Используйте фреймворки, которые имеют встроенную защиту против CSRF, например .NET. Также важно правильно настроить фреймворк. Если ваш фреймворк не имеет защиты от CSRF вы можете использовать Anti-CSRF токены.
Anti-CSRF токены
Токены (или synchronizer token) — это способ защиты со стороны сервера. Сервер генерирует случайный уникальный токен для браузера пользователя и проверяет его для каждого запроса.
Токен находится в скрытом поле, должен быть непредсказуемым случайным числом и иметь небольшое время жизни, без возможности переиспользования.
Токен должен удовлетворять следующим условиям:
- быть уникальным в пределах каждой операции;
- использоваться один раз;
- иметь размер устойчивый к подбору;
- генерироваться криптографически стойким генератором псевдослучайных чисел;
- иметь ограниченное время жизни.
Использование двух токенов
Смысл этого метода в том, что используются два токена: первый сохраняется в cookies, а второй — в одном из параметров ответа.
В таком случае сервер, получая один из небезопасных запросов, должен проверить оба токена.
Использование флага Same-Site в сookies
Этот флаг помечает куки для определенного домена.
Таким образом проверяется источник запроса, и его не получится выполнить с мошеннического сайта.
Этот флаг поддерживает большинство браузеров. Его стоить использовать как часть общей стратегии защиты от CSRF-атак.
Требуйте подтверждения от пользователя
Для чувствительных действий, вроде перевода денег или смены пароля, требуйте дополнительное действие от юзера (ввод капчи или кода подтверждения).
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]