CSRF avec jeton lié à un cookie non lié à la session
CSRF where token is tied to non-session cookie
La fonctionnalité de changement d’email est vulnérable à CSRF. Elle utilise des jetons, mais ils ne sont pas pleinement intégrés au mécanisme de session. Comptes fournis : wiener:peter et carlos:montoya.
Idée clé
Il existe un cookie
csrfKeyet un paramètre de requêtecsrfpour le changement d’email. Ces deux valeurs sont « synchronisées », mais pas liées à la session.

En copiant la paire (
csrfKey,csrf) d’un compte vers un autre, on peut changer l’email d’une victime sans que cela soit rattaché à sa session.Le champ de recherche enregistre la dernière recherche dans un cookie de session (
last searchTerm).


Technique (injection CRLF via la recherche)
On peut injecter des en-têtes via la recherche pour forcer le navigateur à définir un cookie arbitraire.
Une simple chaîne comme hello csrfKey=aZCI... n’est pas interprétée.

En revanche, avec retour chariot + saut de ligne (\r = %0d, \n = %0a) :

Exemple fonctionnel :

→ interprété comme un Set-Cookie côté réponse.

Pour un contexte cross-site, préciser SameSite=none pour que le cookie accompagne la requête suivante depuis l’exploit.
Exemple (dans la barre d’adresse / requête de recherche) :
Exploit hébergé (serveur d’exploit)
Forcer le cookie
csrfKeychez la victime via une requête image vers la page de recherche (qui réécrit l’en-tête) :
Mis à jour
Ce contenu vous a-t-il été utile ?