Влияние
Подделка межсайтовых запросов (CSRF) позволяет злоумышленнику обманом заставить браузер жертвы выполнить нежелательные действия на другом веб-сайте, где жертва в настоящее время аутентифицирована. Поскольку браузеры автоматически включают в запросы внешние учетные данные, такие как файлы cookie, злоумышленник может подделать операции по изменению состояния, такие как изменение паролей, удаление данных или инициирование транзакций, без ведома пользователя.
Основная причина
Основная причина CSRF — поведение веб-браузера по умолчанию, отправляющее файлы cookie, связанные с доменом, всякий раз, когда к этому домену делается запрос, независимо от источника запроса [S1]. Без специальной проверки того, что запрос был намеренно инициирован из собственного пользовательского интерфейса приложения, сервер не может отличить законное действие пользователя от поддельного.
Механизмы защиты Django CSRF
Django предоставляет встроенную систему защиты для снижения этих рисков посредством интеграции промежуточного программного обеспечения и шаблонов [S2].
Активация промежуточного программного обеспечения
django.middleware.csrf.CsrfViewMiddleware отвечает за защиту CSRF и обычно включен по умолчанию [S2]. Его необходимо размещать перед любым промежуточным программным обеспечением представления, которое предполагает, что атаки CSRF уже обработаны. [S2].
Реализация шаблона
Для любых внутренних форм POST разработчики должны включить тег {% csrf_token %} внутри элемента <form> [S2]. Это гарантирует, что в запрос будет включен уникальный секретный токен, который затем сервер проверяет на соответствие сеансу пользователя.
Риски утечки токенов
Важнейшей деталью реализации является то, что {% csrf_token %} никогда не следует включать в формы, предназначенные для внешних URL-адресов [S2]. Это приведет к утечке секретного токена CSRF третьей стороне, что может поставить под угрозу безопасность сеанса пользователя [S2].
Защита на уровне браузера: файлы cookie SameSite
В современных браузерах появился атрибут SameSite для заголовка Set-Cookie, чтобы обеспечить уровень глубокой защиты [S1].
- Строгий: файл cookie отправляется только в собственном контексте, то есть сайт в строке URL соответствует домену файла cookie [S1].
- Слабость: Файл cookie не отправляется при межсайтовых подзапросах (например, изображений или фреймов), а отправляется, когда пользователь переходит на исходный сайт, например, переходя по стандартной ссылке [S1].
Как FixVibe проверяет это
FixVibe теперь включает защиту CSRF в виде закрытой активной проверки. После проверки домена active.csrf-protection проверяет обнаруженные формы изменения состояния, проверяет входные данные в форме CSRF-токена и сигналы файлов cookie SameSite, затем пытается отправить поддельное происхождение с низким уровнем воздействия и сообщает только тогда, когда сервер принимает его. Проверки файлов cookie также выявляют слабые атрибуты SameSite, которые снижают уровень защиты CSRF.