Impacte
La falsificació de sol·licituds entre llocs (CSRF) permet a un atacant enganyar el navegador d'una víctima perquè realitzi accions no desitjades en un lloc web diferent on la víctima està autenticada actualment. Com que els navegadors inclouen automàticament credencials ambientals com les galetes a les sol·licituds, un atacant pot forjar operacions de canvi d'estat, com ara canviar contrasenyes, suprimir dades o iniciar transaccions, sense que l'usuari ho sàpiga.
Causa arrel
La causa fonamental de CSRF és el comportament predeterminat del navegador web d'enviar galetes associades a un domini sempre que es fa una sol·licitud a aquest domini, independentment de l'origen de la sol·licitud [S1]. Sense una validació específica que una sol·licitud s'ha activat intencionadament des de la interfície d'usuari de l'aplicació, el servidor no pot distingir entre una acció d'usuari legítima i una de falsificada.
Mecanismes de protecció de Django CSRF
Django proporciona un sistema de defensa integrat per mitigar aquests riscos mitjançant la integració de programari intermedi i plantilles [S2].
Activació de middleware
El django.middleware.csrf.CsrfViewMiddleware és responsable de la protecció CSRF i normalment està habilitat per defecte [S2]. S'ha de situar abans de qualsevol programari intermedi de visualització que assumeixi que els atacs CSRF ja s'han gestionat [S2].
Implementació de la plantilla
Per als formularis POST interns, els desenvolupadors han d'incloure l'etiqueta {% csrf_token %} dins de l'element <form> [S2]. Això garanteix que s'inclogui un testimoni únic i secret a la sol·licitud, que després el servidor valida contra la sessió de l'usuari.
Riscos de fuga de testimonis
Un detall crític de la implementació és que {% csrf_token %} no s'ha d'incloure mai als formularis orientats a URL externs [S2]. En fer-ho, es filtraria el testimoni CSRF secret a un tercer, cosa que podria comprometre la seguretat de la sessió de l'usuari [S2].
Defensa a nivell de navegador: galetes del mateix lloc
Els navegadors moderns han introduït l'atribut SameSite per a la capçalera Set-Cookie per proporcionar una capa de defensa en profunditat [S1].
- Estricte: la galeta només s'envia en un context de primera part, és a dir, el lloc de la barra d'URL coincideix amb el domini de la galeta [S1].
- Lax: La galeta no s'envia en subsol·licituds entre llocs (com ara imatges o marcs), sinó que s'envia quan un usuari navega al lloc d'origen, com ara seguint un enllaç estàndard [S1].
Com ho prova FixVibe
FixVibe ara inclou la protecció CSRF com a comprovació activa. Després de la verificació del domini, active.csrf-protection inspecciona els formularis de canvi d'estat descoberts, comprova si hi ha entrades en forma de testimoni CSRF i senyals de galetes de SameSite, després intenta enviar un origen falsificat de baix impacte i només informa quan el servidor ho accepta. Les comprovacions de galetes també marquen els atributs febles de SameSite que redueixen la defensa CSRF en profunditat.