CSRF - это, по сути, злоумышленник, использующий существующий сеанс пользователя посредством работы куки в браузере.Основная проблема заключается в том, что файл cookie отправляется с запросом независимо от того, куда (из какого источника, т. Е. Домена) поступает запрос из , единственное, что имеет значение, это куда он направляется в ,Таким образом, если пользователь вошел в приложение (имея сессионный cookie), злоумышленник может попытаться заставить этого пользователя посетить свой вредоносный веб-сайт, откуда злоумышленник может отправлять запросы в домен приложения с учетными данными пользователя (полностьюОтправка пользователя в приложение, или, что еще более тонко, путем создания ajax-запросов.
Обратите внимание, что это применимо только в том случае, если аутентификация в приложении основана на чем-то, что автоматически отправляется браузером, наиболее очевидно, на файл cookie сеанса,но, например, обычная проверка подлинности http или проверка подлинности сертификата клиента также потенциально уязвимы.Также CSRF применяется только к запросам, которые что-то изменяют (состояние или данные).
Существует одна важная вещь, играющая роль, та же политика происхождения (SOP) - это браузеры.Немного упрощенный, это означает, что если что-то загружено из одного домена (или, точнее, из источника), то другой домен не будет иметь доступа.
Таким образом, чтобы защитить от атаки, описанной выше, и предотвратить атакующего самостоятельноВ домене, в котором пользователь отправляет нежелательные запросы в приложение, в которое он вошел, возможны несколько различных стратегий.
Токены синхронизатора
Приложение генерирует токен csrf и сохраняет его всеанс пользователя (на стороне сервера), а также отправляет его клиенту, например, записывая его в каждой форме в скрытом поле или в одном отдельном поле, где Javascript может читать его и добавлять в запросы.Это работает, потому что злоумышленник в своем домене не может создать форму или запрос с допустимым токеном, который находится в сеансе пользователя, а также злоумышленник не может прочитать токен со страницы приложения.Конечно, злоумышленник может попытаться загрузить форму заявки для получения токена, но тогда ему потребуются учетные данные.Атакующему нужен как действительный сеанс пользователя, так и соответствующий токен csrf.Злоумышленник может иметь собственную учетную запись для входа в систему, но в любом случае он может просто выполнить операцию.Или он может иметь токен csrf, но не прошедший проверку подлинности или для учетной записи с более низкими привилегиями.Но у него не может быть и того и другого, и в этом суть.
Таким образом, эта защита в основном проверяет, что запрос поступает из источника, который фактически был предоставлен законным приложением, а не от кого-то другого.
Обратите внимание, чтов этом случае установка токена в файле cookie не имеет смысла, поскольку файл cookie будет отправляться автоматически, как файл cookie сеанса.
Двойное размещение
Другая стратегия заключается в создании токена, иустановите его как cookie для клиента.Затем клиент читает токен из cookie и также отправляет тот же токен, что и заголовок запроса.Сервер только сравнивает, содержат ли заголовок запроса и cookie один и тот же токен.Это работает, потому что злоумышленник не может прочитать токен приложения из файла cookie, установленного другим источником (см. SOP выше), но приложение в легитимном домене может.Таким образом, клиент, отправляющий запрос, эффективно доказал, что он выполняется в легальном домене приложения.Преимущество этого заключается в том, что приложение не имеет состояния и не требует сеанса.Недостатком является то, что он немного менее безопасен.
(Интересно, что токен в этом случае может быть даже сгенерирован на клиенте, он все еще работает, потому что злоумышленник в своем собственном домене не может установить или прочитать cookie домена приложения, но он определенно менее безопасен, так какявляется криптографической операцией в браузере.)
Проверка реферера или источника
Как вы правильно заметили, другой стратегией может быть проверка реферера или источника запроса.Это в основном работает, но считается менее безопасным.В то время как двойная публикация считается достаточно безопасной для многих приложений, проверка реферера / источника в основном не выполняется.Я думаю, что в этом есть сильный исторический элемент, но все же на менее безопасен.
Есть много аспектов проблемы, некоторые из которых приходят на ум:
- Отправка заголовка реферера / источника может быть предотвращена злоумышленником в его собственном домене.Таким образом, приложение не будет знать, что это другой домен - оно просто не будет иметь информацию.Конечно, вы можете реализовать его так, чтобы он нуждался в реферере и / или источнике, но это приведет к потенциальным ошибкам и проблемам, когда браузеры по какой-то причине не отправляют его и т. Д.
- Реферер и источник могутбыть подделанным при некоторых обстоятельствах.Например, старые уязвимые плагины браузера (Java, Flash ... кто-нибудь еще помнит Flash?) Позволяли устанавливать любые заголовки, злоумышленнику нужно было только установить один из них в браузере жертвы - и у всех были.
- Расширения браузера также могут устанавливать / изменять заголовки, поэтому злоумышленник может попытаться установить вредоносное расширение установленным пользователем-жертвой.
- Источник устанавливается только современными браузерами.Меньше проблем сейчас, большинство людей используют браузер, который устанавливает и реферер, и источник.
Так что по этим причинам простая проверка реферера / источника не очень надежна, и должен быть еще один уровень защиты.place.
Файлы cookie SameSite
Новым изобретением Google в Chrome является атрибут SameSite для файлов cookie (в дополнение к уже существующим и широко распространенным атрибутам httpOnly и secure cookie),На данный момент он поддерживается только Chrome, а не другими браузерами.
Как уже говорилось выше, основная проблема заключается в том, что файлы cookie (т. Е. Файлы cookie сеанса) отправляются на сервер на основе цели запроса, ине происхождение.Это означает, что если сайт attacker.com отправляет страницу пользователю и эта страница отправляет запрос на публикацию из браузера на legitapp.com, любой файл cookie, установленный legitapp.com, будет отправляться на legitapp.com.Таким образом, если пользователь вошел на legitapp.com и зашел на сайт attacker.com, существующий сеанс можно использовать.
Это изменяется атрибутом cookie SameSite , который делает cookie неотправлять в тех случаях, когда исходный домен отличается от целевого.Он может быть установлен как «строгий» или «слабый», что в основном определяет поведение запроса GET, но с любым из них будет предотвращать CSRF для запросов не-GET.