Différences

Ci-dessous, les différences entre deux révisions de la page.

--- cyber:vulnerabilite:cross_site_request_forgery [2025/07/03 12:12] – [Expérimenter] admin
+++ cyber:vulnerabilite:cross_site_request_forgery [2025/07/03 12:23] (Version actuelle) – [CWEs] admin
@@ Ligne 59: / Ligne 59: @@
   * Si après avoir navigué sur la page, l'action est réalisée sans avoir eu d'interaction supplémentaire, l'attaque est possible.
-<quote>
+<WRAP center round info>
-{Pro-tips} : pour utiliser deux comptes authentifiés sur la même application, vous pouvez utiliser la navigation privée, ou les [containers tabs->https://support.mozilla.org/fr/kb/utiliser-conteneurs-firefox]. Sinon, il est possible d'utiliser l'extension [Pwnfox->https://addons.mozilla.org/en-US/firefox/addon/pwnfox/] disponible seulement pour le navigateur Firefox.
+**Pro-tips** : pour utiliser deux comptes authentifiés sur la même application, vous pouvez utiliser la navigation privée, ou les [[https://support.mozilla.org/fr/kb/utiliser-conteneurs-firefox|containers tabs]]. Sinon, il est possible d'utiliser l'extension [[https://addons.mozilla.org/en-US/firefox/addon/pwnfox/|Pwnfox]] disponible seulement pour le navigateur Firefox.
-</quote>
+</WRAP>
-<h4>Exploiter</h4>
+==== Exploiter ====
-Consulter les solutions de chaque challenge.
+===== Conséquences potentielles =====
-{{{Conséquences potentielles}}}
 Les conséquences potentielles de ce type d’attaque dépendent grandement de la nature de l’application ciblée. Par exemple, dans le cas d’une application bancaire vulnérable, il peut être possible :
--* D’usurper un compte utilisateur (par exemple en exploitant un formulaire de changement de mot de passe ou d'email) ;
+  * D’usurper un compte utilisateur (par exemple en exploitant un formulaire de changement de mot de passe ou d'email) ;
--* De modifier les informations de compte (telles que les adresses de contact ou encore les informations personnelles) ;
+  * De modifier les informations de compte (telles que les adresses de contact ou encore les informations personnelles) ;
--* De déclencher des transactions financières (comme des achats ou des paiements) sans le consentement de l’utilisateur ;
+  * De déclencher des transactions financières (comme des achats ou des paiements) sans le consentement de l’utilisateur ;
--* D’ajouter des bénéficiaires ou des comptes tiers pour les transactions financières.
+  * D’ajouter des bénéficiaires ou des comptes tiers pour les transactions financières.
+===== Contres-mesures =====
-{{{Contres-mesures}}}
 Les contre-mesures suivantes peuvent être mises en œuvre :
--* {{Utiliser des jetons cryptographiques pour associer une demande à une action spécifique.}} Le jeton peut être régénéré à chaque demande, de sorte que si une demande avec un jeton invalide est reçue par le serveur, elle peut être écartée de manière fiable. Le jeton est considéré comme invalide s’il est arrivé avec une demande autre que l’action à laquelle il était censé être associé.
+  * **Utiliser des jetons cryptographiques pour associer une demande à une action spécifique.** Le jeton peut être régénéré à chaque demande, de sorte que si une demande avec un jeton invalide est reçue par le serveur, elle peut être écartée de manière fiable. Le jeton est considéré comme invalide s’il est arrivé avec une demande autre que l’action à laquelle il était censé être associé.
--* {{Utiliser un second facteur d’authentification.}} L’utilisateur peut être invité à confirmer une action chaque fois qu’une action concernant des données potentiellement sensibles est invoquée. De cette façon, même si l’attaquant parvient à faire en sorte que l’utilisateur clique sur un lien malveillant et demande l’action souhaitée, l’utilisateur peut encore refuser la confirmation et ainsi être averti que son compte a potentiellement été compromis.
+  * **Utiliser un second facteur d’authentification.** L’utilisateur peut être invité à confirmer une action chaque fois qu’une action concernant des données potentiellement sensibles est invoquée. De cette façon, même si l’attaquant parvient à faire en sorte que l’utilisateur clique sur un lien malveillant et demande l’action souhaitée, l’utilisateur peut encore refuser la confirmation et ainsi être averti que son compte a potentiellement été compromis.
--* {{Mettre en place l'option 'Same-Site' sur les cookies de session.}} L'option {Same-Site} peut être précisée lors de l'attribution d'un cookie par le serveur. Cet attribut permet de réduire le domaine de diffusion du cookie associé selon trois niveaux de politiques : {None}, {Lax} et {Strict}.
+  * **Mettre en place l'option 'Same-Site' sur les cookies de session.** L'option **Same-Site** peut être précisée lors de l'attribution d'un cookie par le serveur. Cet attribut permet de réduire le domaine de diffusion du cookie associé selon trois niveaux de politiques : **None**, **Lax** et **Strict**.
+====== Comment cela fonctionne ? ======
+===== Exemple 1 =====
+Le formulaire HTML ci-dessous permet à un utilisateur légitime de modifier l'email avec lequel son compte est associé :
+<code html>
+<form action="/account/edit-email" method="post">
+    <input type="email" name="email">
+    <button type="submit">Change Email</button>
+</form>
+</code>
+La requête envoyée via ce formulaire se présente comme ceci :
+<code HTTP>
+POST /account/edit-email HTTP/2
+Host: example.ex
+Cookie: session=JV1WLK4mrRS3o4zX64NOS2fmADrFKIgo
+email=new-email@root-me.org
+</code>
+À la réception de cette requête, le serveur modifie l'email du compte sans plus de vérifications. Ce formulaire respecte bien les 3 prérequis présentés dans le point [[#Explorer]]. Pour mettre en place l'attaque, on ré-utilise le formulaire HTML légitime que l'on modifie légèrement pour l'héberger sur un serveur que l'on contrôle :
+<code html>
+<form id="malicious" action="https://example.ex/account/edit-email" method="post">
+    <input type="email" name="email" value="hackerman@root-me.org" />
+    <button type="submit">Change Email</button>
+</form>
+<script>
+    document.getElementById('malicious').submit();
+</script>
+</code>
+<WRAP center round important>
+**Attention** : le formulaire d'exploitation est hébergé sur un serveur dont le nom de domaine est différent de celui à destination de la requête. Il est important de bien préciser le domaine de destination dans le champ **action** de la balise **form**. Sinon, la requête sera dirigée vers <code>/account/edit-email</code> du domaine appartenant à l'attaquant.
+</WRAP>
+Le JavaScript permet d'automatiquement soumettre le formulaire dès que la page est chargée. Si la personne visitant la page est un utilisateur de l'application <code>example.ex</code>, la requête envoyée contiendra son cookie de session.
+Notre attaque est prête à être exploitée. On transmet à la victime l'URL contenant la charge ci-dessus et on patiente jusqu'à ce que celle-ci visite la page. Une fois fait, il ne reste alors qu'à utiliser la fonctionnalité d'oubli de mot de passe en précisant le mail tout juste changé <code>hackerman@root-me.org</code> pour compromettre totalement le compte de la victime.
+===== Exemple 2 =====
+Dans ce nouvel exemple, le formulaire est protégé par un jeton cryptographique. Ce jeton est créé par le serveur à la réception d'une requête vers <code>/account</code> et transmis dans un champ caché du formulaire (nommé dans l'exemple <code>csrf-token</code>) avec le reste de la réponse. Le formulaire ressemble à ceci :
+<code HTML>
+<form action="/account/edit-email" method="post">
+    <input type="hidden" name="csrf-token" value="4db830b9ca7301988ed14e3ed04a47c1">
+    <input type="email" name="email">
+    <button type="submit">Change Email</button>
+</form>
+</code>
+Un utilisateur légitime voulant modifier son email, va renvoyer le même jeton que celui transmis par le serveur. Ce-dernier va pouvoir faire la liaison entre la première requête vers <code>/account</code> et la seconde requête vers <code>/account/edit-mail</code> qui contient le même jeton. Dans le cas où ces jetons ne seraient pas égaux, cela signifie que la seconde requête ne provient pas d'une première requête vers <code>/account</code>, et donc que la requête est probablement illégitime ; l'email n'est alors pas modifié par le serveur.
+<code HTTP>
+POST /account/edit-email HTTP/2
+Host: example.ex
+Cookie: session=JV1WLK4mrRS3o4zX64NOS2fmADrFKIgo
+csrf-token=4db830b9ca7301988ed14e3ed04a47c1&email=new-email@root-me.org
+</code>
+Il existe malgré tout des techniques pour contourner ce jeton. Imaginons que ce dernier n'est pas lié à un utilisateur, mais commun à tous. Cela signifie que n'importe quel utilisateur réalisant une requête vers <code>/account</code> génère un jeton qui peut être utilisé par n'importe qui pour légitimer une requête vers <code>/account/edit-mail</code>.
+Un attaquant peut alors générer un jeton valide au préalable de son exploitation et le placer comme valeur dans sa charge malveillante :
+<code HTML>
+<form id="malicious" action="https://example.ex/account/edit-email" method="post">
+    <input type="hidden" name="csrf-token" value="f7cc02f6ba84fbe0d2d90ca3fee3946d">
+    <input type="email" name="email" value="hackerman@root-me.org" />
+    <button type="submit">Change Email</button>
+</form>
+<script>
+    document.getElementById('malicious').submit();
+</script>
+</code>
+Les jetons étant communs à tous les utilisateurs, le serveur va simplement vérifier que le token est dans sa base de données. Étant générée en amont sur le compte de l'attaquant de manière légitime, la requête est validée et l'attaque réussie.
+**Pour que la vérification par jeton CSRF soit efficace, il est important que celui-ci soit généré de manière aléatoire, unique pour chaque utilisateur et être associé à une durée de validité limitée.**
+====== CWEs ======
+  * [[https://cwe.mitre.org/data/definitions/352.html|CWE-352 : Cross-Site Request Forgery (CSRF)]]
+The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.
+  * [[https://cwe.mitre.org/data/definitions/306.html|CWE-306 : Missing Authentication for Critical Function]]
+The software does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
+  * [[https://cwe.mitre.org/data/definitions/664.html|CWE-664 : Improper Control of a Resource Through its Lifetime]]
+The software does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.
+  * [[https://cwe.mitre.org/data/definitions/732.html|CWE-732 : Incorrect Permission Assignment for Critical Resource]]
+The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
+  * [[https://cwe.mitre.org/data/definitions/1275.html|CWE-1275 : Sensitive Cookie with Improper SameSite Attribute]]
+The SameSite attribute for sensitive cookies is not set, or an insecure value is used.
+====== References ======
+URL :
+  * https://repository.root-me.org/Exploitation%20-%20Web/FR%20-%20les%20attaques%20CSRF.pdf
+  * https://repository.root-me.org/Exploitation%20-%20Web/EN%20-%20CSRF:%20Attack%20and%20defense.pdf
+  * https://repository.root-me.org/Exploitation%20-%20Web/EN%20-%20OWASP%20Cross-site%20Request%20Forgery%20CSRF.pdf
 ====== Retour fiches vulnérabilités ======
   * [[cyber:vulnerabilite:accueil|Cyber fiches vulnérabilités]]