Влијание
Фалсификувањето на барањата меѓу страниците (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.