* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
[**DragonJAR Security Conference est un événement international de cybersécurité**](https://www.dragonjarcon.org/) avec plus d'une décennie qui se tiendra les 7 et 8 septembre 2023 à Bogotá, en Colombie. C'est un événement de contenu technique de haut niveau où les dernières recherches en espagnol sont présentées, attirant des hackers et des chercheurs du monde entier.\
La directive racine spécifie le dossier racine pour Nginx. Dans l'exemple ci-dessus, le dossier racine est `/etc/nginx`, ce qui signifie que nous pouvons accéder aux fichiers dans ce dossier. La configuration ci-dessus n'a pas d'emplacement pour `/ (location / {...})`, seulement pour `/hello.txt`. En raison de cela, la directive `root` sera définie globalement, ce qui signifie que les demandes à `/` vous amèneront au chemin local `/etc/nginx`.
Une demande aussi simple que `GET /nginx.conf` révélerait le contenu du fichier de configuration Nginx stocké dans `/etc/nginx/nginx.conf`. Si la racine est définie sur `/etc`, une demande `GET` à `/nginx/nginx.conf` révélerait le fichier de configuration. Dans certains cas, il est possible d'accéder à d'autres fichiers de configuration, journaux d'accès et même à des informations d'identification chiffrées pour l'authentification de base HTTP.
Le contenu suivant provient d'un livre de piratage sur les techniques de piratage. Le contenu suivant provient du fichier network-services-pentesting/pentesting-web/nginx.md. Traduisez le texte anglais pertinent en français et renvoyez la traduction en conservant la syntaxe markdown. Ne traduisez pas les choses comme le code, les noms de techniques de piratage, les mots de piratage, les noms de plateformes cloud/SaaS (comme Workspace, aws, gcp...), le mot 'leak', pentesting et les balises markdown. N'ajoutez également rien d'autre que la traduction et la syntaxe markdown.
Donc, si vous trouvez un serveur Nginx, vous devriez vérifier cette vulnérabilité. De plus, vous pouvez la découvrir si vous constatez que la force brute des fichiers/répertoires se comporte de manière étrange.
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/)
Les caractères de nouvelle ligne pour les requêtes HTTP sont \r (Retour chariot) et \n (Saut de ligne). L'encodage d'URL des caractères de nouvelle ligne donne la représentation suivante des caractères `%0d%0a`. Lorsque ces caractères sont inclus dans une requête telle que `http://localhost/%0d%0aDetectify:%20clrf` à un serveur avec une mauvaise configuration, le serveur répondra avec un nouvel en-tête nommé `Detectify` car la variable $uri contient les caractères de nouvelle ligne décodés de l'URL.
En savoir plus sur les risques d'injection CRLF et de fractionnement de réponse 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/).
Dans certains cas, les données fournies par l'utilisateur peuvent être traitées comme une variable Nginx. Il n'est pas clair pourquoi cela peut se produire, mais ce n'est pas si rare ou facile à tester comme on peut le voir dans ce [rapport H1](https://hackerone.com/reports/370094). Si nous recherchons le message d'erreur, nous pouvons voir qu'il se trouve dans le module de filtre SSI, révélant ainsi que cela est dû à SSI.
Nous avons scanné cette mauvaise configuration et avons trouvé plusieurs instances où un utilisateur pouvait imprimer la valeur des variables Nginx. Le nombre d'instances vulnérables trouvées a diminué, ce qui pourrait indiquer que cela a été corrigé.
Avec `proxy_pass` de Nginx, il est possible d'intercepter les erreurs et les en-têtes HTTP créés par le backend. Cela est très utile si vous voulez masquer les messages d'erreur et les en-têtes internes afin qu'ils soient gérés par Nginx. Nginx servira automatiquement une page d'erreur personnalisée si le backend répond avec une telle page. Mais que se passe-t-il si Nginx ne comprend pas qu'il s'agit d'une réponse HTTP ?
Si un client envoie une requête HTTP invalide à Nginx, cette requête sera transmise telle quelle au backend, et le backend répondra avec son contenu brut. Ensuite, Nginx ne comprendra pas la réponse HTTP invalide et la transmettra simplement au client. Imaginez une application uWSGI comme celle-ci :
`proxy_intercept_errors` servira une réponse personnalisée si le backend a un statut de réponse supérieur à 300. Dans notre application uWSGI ci-dessus, nous enverrons une `Erreur 500` qui sera interceptée par Nginx.
La directive [merge\_slashes](http://nginx.org/en/docs/http/ngx\_http\_core\_module.html#merge\_slashes) est définie par défaut sur "on", ce qui est un mécanisme pour compresser deux ou plusieurs barres obliques en une seule, donc `///` deviendrait `/`. Si Nginx est utilisé en tant que reverse-proxy et que l'application qui est proxifiée est vulnérable à l'inclusion de fichiers locaux, l'utilisation de barres obliques supplémentaires dans la requête pourrait laisser place à une exploitation. Cela est décrit en détail par [Danny Robinson et Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).
> définit la valeur résultante si la valeur source ne correspond à aucune des variantes spécifiées. Lorsque la valeur par défaut n'est pas spécifiée, la valeur résultante par défaut sera une chaîne vide.
Il est facile d'oublier la valeur "par défaut". Ainsi, un **malfaiteur peut contourner ce "contrôle d'autorisation"** en accédant simplement à un **cas inexistant dans /map-poc** comme `https://targethost.com/map-poc/another-private-area`.
Selon cet article: [http://blog.zorinaq.com/nginx-resolver-vulns/](http://blog.zorinaq.com/nginx-resolver-vulns/) **Il pourrait être possible de falsifier les enregistrements DNS** pour Nginx si vous **connaissez le serveur DNS que Nginx** utilise (et vous pouvez intercepter la communication d'une manière ou d'une autre, donc cela **n'est pas valable si 127.0.0.1** est utilisé) et le **domaine qu'il demande**.
Si le serveur nginx est configuré pour passer les en-têtes Upgrade et Connection, une [**attaque d'h2c Smuggling**](../../pentesting-web/h2c-smuggling.md) pourrait être effectuée pour accéder à des points de terminaison protégés/internes.
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 sera pas vérifié par nginx.
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'est donc pas important qu'un chemin soit spécifié dans l'URL de proxy\_pass.**
Detectify a créé un référentiel 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!
Gixy est un outil d'analyse de la configuration Nginx. L'objectif principal de Gixy est de prévenir les mauvaises configurations de sécurité et d'automatiser la détection des failles.
[**DragonJAR Security Conference es un evento internacional de ciberseguridad**](https://www.dragonjarcon.org/) avec plus d'une décennie qui se tiendra les 7 et 8 septembre 2023 à Bogotá, en Colombie. C'est un événement de contenu technique élevé où les dernières recherches en espagnol sont présentées, attirant des hackers et des chercheurs du monde entier.\
Inscrivez-vous dès maintenant sur le lien suivant et ne manquez pas cette grande conférence!:
* Travaillez-vous dans une **entreprise de cybersécurité**? Voulez-vous voir votre **entreprise annoncée dans HackTricks**? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF**? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).