CSRF

CSRF (cross-site request forgery, подделка межсайтовых запросов) — вид атак на сайт, при которой злоумышленник с помощью мошеннического сайта или скрипта заставляет браузер пользователя выполнять на доверенном сайте действия от его имени: отправлять сообщения, менять пароли, переводить деньги со счета на счет и пр. В атаке используются недостатки протокола HTTP.

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

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

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

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

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

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

Для выполнения CSRF необходимы несколько условий:

• на уязвимом сайте есть действие, которое хакер хочет выполнить от имени жертвы, например изменить адрес @mail, осуществить перевод денежных средств, изменить пароль и так далее;
• злоумышленник заранее знает все параметры запроса, которые ожидает увидеть уязвимый сайт. Даже незначительное отличие в тексте повлияет на работоспособность;
• действие полагается только на файлы cookies для верификации пользователя и выполняется с помощью HTTP-запросов.

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

Либо злоумышленник может обманом заставить жертву загрузить или отправить информацию. Например, через фишинговую ссылку.

Она может быть скрыта в теге изображения:

<img src=“фишинговая ссылка” width=“0” height=“0” border=“0”>

Или замаскирована под обычную ссылку:

<a href=“фишинговая ссылка”>Unsubscribe here</a> 

Как защитить сайт от CSRF-атак

Некоторые фреймворки имеют встроенную защиту от CSRF-атак. Например .NET или Laravel. Если ее нет, можно использовать следующие способы.

SOP

SOP (same-origin policy, политика одинакового источника) определяет то, как именно скрипт или документ, который загружен из оригинального источника (origin), будет взаимодействовать с ресурсом, загруженным из другого источника. Две страницы имеют одинаковый источник, если у них совпадают хост (host), порт (port) и протокол (http или https). Часто можно встретить также запись вида scheme/host/port tuple. Это позволяет изолировать документы, которые могут нанести вред, и снизить количество вероятных векторов атак.

Токены CSRF

CSRF-токены (или anti-CSRF-токены) напоминают cookies. Это такие же данные, которые сервер отправляет браузеру в ожидании получить их обратно, но отличие в следующем: сервер должен отправить браузеру уникальный токен и проверить, присылает ли его браузер в ответ в запросе. Если токены совпадают, запрос действителен, если нет — отклоняется.

Токен должен удовлетворять требованиям:

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

Также можно использовать два токена. Кроме токена, сохраненного в параметрах ответа, существует второй, размещенный в сессионных cookies. Таким образом сервер, получая запрос, проверяет два токена вместо одного. Такую защиту намного сложнее преодолеть.

Флаг Same-Site Cookies

Метод похож на использование SOP. Отличие в том, что флаг Same-Site помечает куки для одного доменного имени. В результате источник запроса подвергается проверке. Считается, что cookies и источник запроса имеют одинаковое происхождение, если протокол, порт (если применимо) и хост (но не IP-адрес) одинаковы для обоих. Таким образом не получится отправить запрос с мошеннического сайта. Флаг поддерживает подавляющее большинство современных браузеров, и его использование является хорошей практикой в стратегии защиты.

Подтверждение действий от пользователя

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