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