Ndikimi
Falsifikimi i Kërkesave Ndër-Site (CSRF) lejon një sulmues të mashtrojë shfletuesin e viktimës për të kryer veprime të padëshiruara në një faqe interneti të ndryshme ku viktima është aktualisht e vërtetuar. Për shkak se shfletuesit përfshijnë automatikisht kredencialet e ambientit si kuki në kërkesa, një sulmues mund të falsifikojë operacione të ndryshimit të gjendjes—si ndryshimi i fjalëkalimeve, fshirja e të dhënave ose fillimi i transaksioneve—pa dijeninë e përdoruesit.
Shkaku rrënjësor
Shkaku themelor i CSRF është sjellja e paracaktuar e shfletuesit të uebit për dërgimin e skedarëve të skedarëve të lidhur me një domen sa herë që bëhet një kërkesë në atë domen, pavarësisht nga origjina e kërkesës [S1]. Pa vërtetim specifik që një kërkesë është shkaktuar qëllimisht nga ndërfaqja e përdoruesit të aplikacionit, serveri nuk mund të bëjë dallimin midis një veprimi të ligjshëm të përdoruesit dhe një veprimi të falsifikuar.
Mekanizmat e mbrojtjes së Django CSRF
Django ofron një sistem mbrojtjeje të integruar për të zbutur këto rreziqe nëpërmjet integrimit të softuerit të mesëm dhe modelit [S2].
Aktivizimi i programit të mesëm
django.middleware.csrf.CsrfViewMiddleware është përgjegjës për mbrojtjen CSRF dhe zakonisht aktivizohet si parazgjedhje [S2]. Ai duhet të pozicionohet përpara çdo pamjeje të softuerit të mesëm që supozon se sulmet CSRF tashmë janë trajtuar [S2].
Zbatimi i shabllonit
Për çdo formular të brendshëm POST, zhvilluesit duhet të përfshijnë etiketën {% csrf_token %} brenda elementit <form> [S2]. Kjo siguron që një shenjë unike sekrete të përfshihet në kërkesë, të cilën serveri e vërteton më pas kundrejt seancës së përdoruesit.
Rreziqet e rrjedhjes së shenjave
Një detaj kritik i zbatimit është se {% csrf_token %} nuk duhet të përfshihet kurrë në format që synojnë URL-të e jashtme [S2]. Një veprim i tillë do t'ia nxirrte një palë të tretë kodin sekret CSRF, duke rrezikuar potencialisht sigurinë e sesionit të përdoruesit [S2].
Mbrojtja e nivelit të shfletuesit: Cookies SameSite
Shfletuesit modernë kanë prezantuar atributin SameSite për kokën Set-Cookie për të ofruar një shtresë të mbrojtjes në thellësi [S1].
- Rrepte: Kuki dërgohet vetëm në një kontekst të palës së parë, që do të thotë se faqja në shiritin e URL-së përputhet me domenin e skedarit të kukive [S1].
- Laks: Kuki nuk dërgohet në nënkërkesa ndër-site (të tilla si imazhe ose korniza), por dërgohet kur një përdorues lundron në faqen e origjinës, si p.sh. duke ndjekur një lidhje standarde [S1].
Si e teston FixVibe për të
FixVibe tani përfshin mbrojtjen CSRF si një kontroll aktiv të mbyllur. Pas verifikimit të domenit, active.csrf-protection inspekton format e zbuluara që ndryshojnë gjendjen, kontrollon hyrjet në formë tokeni CSRF dhe sinjalet e kukive SameSite, më pas tenton një paraqitje me origjinë të falsifikuar me ndikim të ulët dhe raporton vetëm kur serveri e pranon atë. Kontrollet e cookie-ve raportojnë gjithashtu atribute të dobëta të SameSite që reduktojnë mbrojtjen në thellësi të CSRF.