CSRF (Cross Site Request Forgery)
Last updated
Last updated
Rejoignez le serveur HackenProof Discord pour communiquer avec des pirates expérimentés et des chasseurs de primes !
Perspectives de piratage Engagez-vous avec du contenu qui explore le frisson et les défis du piratage
Actualités de piratage en temps réel Restez informé du monde du piratage en évolution rapide grâce à des actualités et des informations en temps réel
Dernières annonces Restez informé des dernières primes de bugs lancées et des mises à jour cruciales de la plateforme
Rejoignez-nous sur Discord et commencez à collaborer avec les meilleurs pirates dès aujourd'hui !
La faille Cross-Site Request Forgery (CSRF) est un type de vulnérabilité de sécurité présente dans les applications web. Elle permet aux attaquants d'effectuer des actions au nom d'utilisateurs sans méfiance en exploitant leurs sessions authentifiées. L'attaque est exécutée lorsqu'un utilisateur, connecté à la plateforme d'une victime, visite un site malveillant. Ce site déclenche ensuite des requêtes vers le compte de la victime à travers des méthodes telles que l'exécution de JavaScript, la soumission de formulaires ou le chargement d'images.
Pour exploiter une vulnérabilité CSRF, plusieurs conditions doivent être remplies :
Identifier une action de valeur : L'attaquant doit trouver une action à exploiter, telle que changer le mot de passe de l'utilisateur, son adresse e-mail ou élever ses privilèges.
Gestion de session : La session de l'utilisateur doit être gérée uniquement via des cookies ou l'en-tête d'authentification de base HTTP, car les autres en-têtes ne peuvent pas être manipulés à cette fin.
Absence de paramètres imprévisibles : La requête ne doit pas contenir de paramètres imprévisibles, car ils peuvent empêcher l'attaque.
Vous pourriez capturer la requête dans Burp et vérifier les protections CSRF et pour tester depuis le navigateur, vous pouvez cliquer sur Copier comme fetch et vérifier la requête :
Plusieurs contre-mesures peuvent être mises en place pour se protéger contre les attaques CSRF :
Cookies SameSite : Cet attribut empêche le navigateur d'envoyer des cookies avec des requêtes entre sites. En savoir plus sur les cookies SameSite.
Partage de ressources entre origines : La politique CORS du site victime peut influencer la faisabilité de l'attaque, surtout si l'attaque nécessite la lecture de la réponse du site victime. Apprenez-en plus sur le contournement de CORS.
Vérification de l'utilisateur : Demander le mot de passe de l'utilisateur ou résoudre un captcha peut confirmer l'intention de l'utilisateur.
Vérification des en-têtes Referrer ou Origin : Valider ces en-têtes peut aider à garantir que les requêtes proviennent de sources de confiance. Cependant, une construction soigneuse d'URL peut contourner des vérifications mal implémentées, telles que :
Utiliser http://mal.net?orig=http://example.com
(l'URL se termine par l'URL de confiance)
Utiliser http://example.com.mal.net
(l'URL commence par l'URL de confiance)
Modification des noms de paramètres : Modifier les noms de paramètres dans les requêtes POST ou GET peut aider à prévenir les attaques automatisées.
Jetons CSRF : Incorporer un jeton CSRF unique dans chaque session et exiger ce jeton dans les requêtes ultérieures peut atténuer considérablement le risque de CSRF. L'efficacité du jeton peut être renforcée en imposant CORS.
Comprendre et mettre en œuvre ces défenses est crucial pour maintenir la sécurité et l'intégrité des applications web.
Peut-être que le formulaire que vous souhaitez exploiter est configuré pour envoyer une requête POST avec un jeton CSRF, mais vous devriez vérifier si un GET est également valide et si lorsque vous envoyez une requête GET, le jeton CSRF est toujours validé.
Les applications peuvent mettre en place un mécanisme pour valider les jetons lorsqu'ils sont présents. Cependant, une vulnérabilité apparaît si la validation est complètement ignorée lorsque le jeton est absent. Les attaquants peuvent exploiter cela en supprimant le paramètre portant le jeton, pas seulement sa valeur. Cela leur permet de contourner le processus de validation et de mener une attaque de Cross-Site Request Forgery (CSRF) efficacement.
Les applications ne liant pas les jetons CSRF aux sessions utilisateur présentent un risque de sécurité important. Ces systèmes vérifient les jetons par rapport à un pool global plutôt que de s'assurer que chaque jeton est lié à la session initiale.
Voici comment les attaquants exploitent cela :
S'authentifier avec leur propre compte.
Obtenir un jeton CSRF valide à partir du pool global.
Utiliser ce jeton dans une attaque CSRF contre une victime.
Cette vulnérabilité permet aux attaquants de faire des requêtes non autorisées au nom de la victime, exploitant le mécanisme de validation de jeton inadéquat de l'application.
Si la requête utilise une méthode "étrange", vérifiez si la fonctionnalité de remplacement de méthode fonctionne. Par exemple, si elle utilise une méthode PUT, vous pouvez essayer d'utiliser une méthode POST et envoyer : https://example.com/my/dear/api/val/num?_method=PUT
Cela pourrait également fonctionner en envoyant le paramètre _method dans une requête POST ou en utilisant les en-têtes :
X-HTTP-Method
X-HTTP-Method-Override
X-Method-Override
Si la requête ajoute un en-tête personnalisé avec un jeton à la requête comme méthode de protection CSRF, alors :
Testez la requête sans le jeton personnalisé et aussi l'en-tête.
Testez la requête avec exactement la même longueur mais un jeton différent.
Les applications peuvent mettre en place une protection CSRF en dupliquant le jeton à la fois dans un cookie et un paramètre de requête ou en définissant un cookie CSRF et en vérifiant si le jeton envoyé en backend correspond au cookie. L'application valide les requêtes en vérifiant si le jeton dans le paramètre de requête correspond à la valeur dans le cookie.
Cependant, cette méthode est vulnérable aux attaques CSRF si le site web présente des failles permettant à un attaquant de définir un cookie CSRF dans le navigateur de la victime, comme une vulnérabilité CRLF. L'attaquant peut exploiter cela en chargeant une image trompeuse qui définit le cookie, suivi de l'initiation de l'attaque CSRF.
Voici un exemple de la manière dont une attaque pourrait être structurée:
Notez que si le jeton csrf est lié au cookie de session, cette attaque ne fonctionnera pas car vous devrez définir votre session comme victime, et donc vous vous attaquerez vous-même.
Selon ceci, afin d'éviter les requêtes de pré-vérification en utilisant la méthode POST, voici les valeurs de Content-Type autorisées :
application/x-www-form-urlencoded
multipart/form-data
text/plain
Cependant, notez que la logique des serveurs peut varier en fonction du Content-Type utilisé, donc vous devriez essayer les valeurs mentionnées et d'autres comme application/json
,text/xml
, application/xml
.
Exemple (de ici) d'envoi de données JSON en tant que text/plain :
Lors de la tentative d'envoi de données JSON via une requête POST, l'utilisation de Content-Type: application/json
dans un formulaire HTML n'est pas directement possible. De même, l'utilisation de XMLHttpRequest
pour envoyer ce type de contenu initie une demande de pré-vérification. Néanmoins, il existe des stratégies pour potentiellement contourner cette limitation et vérifier si le serveur traite les données JSON indépendamment du Content-Type :
Utiliser des types de contenu alternatifs : Utilisez Content-Type: text/plain
ou Content-Type: application/x-www-form-urlencoded
en définissant enctype="text/plain"
dans le formulaire. Cette approche teste si le backend utilise les données indépendamment du Content-Type.
Modifier le type de contenu : Pour éviter une demande de pré-vérification tout en garantissant que le serveur reconnaisse le contenu comme JSON, vous pouvez envoyer les données avec Content-Type: text/plain; application/json
. Cela ne déclenche pas de demande de pré-vérification mais pourrait être traité correctement par le serveur s'il est configuré pour accepter application/json
.
Utilisation de fichiers Flash SWF : Une méthode moins courante mais réalisable implique l'utilisation d'un fichier Flash SWF pour contourner de telles restrictions. Pour une compréhension approfondie de cette technique, consultez cet article.
Éviter l'en-tête Référent
Les applications peuvent valider l'en-tête 'Referer' uniquement lorsqu'il est présent. Pour empêcher un navigateur d'envoyer cet en-tête, la balise meta HTML suivante peut être utilisée :
Cela garantit que l'en-tête 'Referer' est omis, contournant potentiellement les vérifications de validation dans certaines applications.
Contournements Regexp
URL Format BypassPour définir le nom de domaine du serveur dans l'URL que le Référent va envoyer dans les paramètres, vous pouvez faire :
La première partie de ce compte rendu CTF explique que dans le code source d'Oak, un routeur est configuré pour traiter les requêtes HEAD comme des requêtes GET sans corps de réponse - une solution de contournement courante qui n'est pas propre à Oak. Au lieu d'un gestionnaire spécifique pour les requêtes HEAD, elles sont simplement transmises au gestionnaire GET mais l'application supprime simplement le corps de réponse.
Par conséquent, si une requête GET est limitée, vous pourriez simplement envoyer une requête HEAD qui sera traitée comme une requête GET.
Si un jeton CSRF est utilisé comme défense, vous pourriez essayer de l'exfiltrer en exploitant une vulnérabilité XSS ou une vulnérabilité Dangling Markup.
D'autres balises HTML5 qui peuvent être utilisées pour envoyer automatiquement une requête GET sont :