Apprenez et pratiquez le hacking AWS :<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Apprenez et pratiquez le hacking GCP : <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez-nous sur****Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Partagez des astuces de hacking en soumettant des PRs aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts github.
Le partage de ressources entre origines multiples (CORS) standard **permet aux serveurs de définir qui peut accéder à leurs ressources** et **quelles méthodes de requête HTTP sont autorisées** depuis des sources externes.
Une politique de **même origine** exige qu'un **serveur demandant** une ressource et le serveur hébergeant la **ressource** partagent le même protocole (par exemple, `http://`), nom de domaine (par exemple, `internal-web.com`), et **port** (par exemple, 80). Selon cette politique, seules les pages web du même domaine et port sont autorisées à accéder aux ressources.
Cet en-tête peut autoriser **plusieurs origines**, une valeur **`null`**, ou un caractère générique **`*`**. Cependant, **aucun navigateur ne prend en charge plusieurs origines**, et l'utilisation du caractère générique `*` est soumise à des **limitations**. (Le caractère générique doit être utilisé seul, et son utilisation avec `Access-Control-Allow-Credentials: true` n'est pas autorisée.)
Cet en-tête est **émis par un serveur** en réponse à une demande de ressource inter-domaines initiée par un site web, le navigateur ajoutant automatiquement un en-tête `Origin`.
Par **défaut**, les requêtes inter-origines sont effectuées sans identifiants comme des cookies ou l'en-tête Authorization. Pourtant, un serveur inter-domaines peut autoriser la lecture de la réponse lorsque des identifiants sont envoyés en définissant l'en-tête `Access-Control-Allow-Credentials` sur **`true`**.
Lors de l'initiation d'une requête inter-domaines dans des conditions spécifiques, telles que l'utilisation d'une **méthode HTTP non standard** (tout sauf HEAD, GET, POST), l'introduction de nouveaux **en-têtes**, ou l'emploi d'une valeur spéciale pour l'en-tête **Content-Type**, une requête préliminaire peut être nécessaire. Cette requête préliminaire, utilisant la méthode **`OPTIONS`**, sert à informer le serveur des intentions de la requête inter-origine à venir, y compris les méthodes HTTP et les en-têtes qu'elle prévoit d'utiliser.
Le protocole **Cross-Origin Resource Sharing (CORS)** exige cette vérification préliminaire pour déterminer la faisabilité de l'opération inter-origine demandée en vérifiant les méthodes, les en-têtes autorisés et la fiabilité de l'origine. Pour une compréhension détaillée des conditions qui contournent la nécessité d'une requête préliminaire, consultez le guide complet fourni par [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests).
Il est crucial de noter que **l'absence d'une requête préliminaire ne supprime pas l'exigence que la réponse contienne des en-têtes d'autorisation**. Sans ces en-têtes, le navigateur est incapable de traiter la réponse de la requête inter-origine.
Considérez l'illustration suivante d'une requête préliminaire visant à utiliser la méthode `PUT` avec un en-tête personnalisé nommé `Special-Request-Header` :
En réponse, le serveur peut renvoyer des en-têtes indiquant les méthodes acceptées, l'origine autorisée et d'autres détails de la politique CORS, comme indiqué ci-dessous :
* **`Access-Control-Allow-Headers`** : Cet en-tête spécifie quels en-têtes peuvent être utilisés lors de la demande réelle. Il est défini par le serveur pour indiquer les en-têtes autorisés dans les demandes du client.
* **`Access-Control-Expose-Headers`** : Grâce à cet en-tête, le serveur informe le client des en-têtes qui peuvent être exposés dans la réponse en plus des en-têtes de réponse simples.
* **`Access-Control-Max-Age`** : Cet en-tête indique combien de temps les résultats d'une demande préliminaire peuvent être mis en cache. Le serveur définit le temps maximum, en secondes, que les informations renvoyées par une demande préliminaire peuvent être réutilisées.
* **`Access-Control-Request-Headers`** : Utilisé dans les demandes préliminaires, cet en-tête est défini par le client pour informer le serveur des en-têtes HTTP que le client souhaite utiliser dans la demande réelle.
* **`Access-Control-Request-Method`** : Cet en-tête, également utilisé dans les demandes préliminaires, est défini par le client pour indiquer quelle méthode HTTP sera utilisée dans la demande réelle.
* **`Origin`** : Cet en-tête est automatiquement défini par le navigateur et indique l'origine de la demande inter-origine. Il est utilisé par le serveur pour évaluer si la demande entrante doit être autorisée ou refusée en fonction de la politique CORS.
Notez qu'en général (selon le type de contenu et les en-têtes définis) dans une **demande GET/POST, aucune demande préliminaire n'est envoyée** (la demande est envoyée **directement**), mais si vous souhaitez accéder aux **en-têtes/corps de la réponse**, cela doit contenir un en-tête _Access-Control-Allow-Origin_ l'autorisant.\
**Par conséquent, CORS ne protège pas contre CSRF (mais cela peut être utile).**
1.**`Access-Control-Request-Local-Network`** : Cet en-tête est inclus dans la demande du client pour signifier que l'enquête vise une ressource de réseau local. Il sert de marqueur pour informer le serveur que la demande provient du réseau local.
2.**`Access-Control-Allow-Local-Network`** : En réponse, les serveurs utilisent cet en-tête pour communiquer que la ressource demandée est autorisée à être partagée avec des entités en dehors du réseau local. Il agit comme un feu vert pour le partage de ressources à travers différentes frontières de réseau, garantissant un accès contrôlé tout en maintenant des protocoles de sécurité.
Une **réponse valide autorisant la demande de réseau local** doit également contenir dans la réponse l'en-tête `Access-Controls-Allow-Local_network: true` :
Notez que l'IP linux **0.0.0.0** fonctionne pour **contourner** ces exigences pour accéder à localhost, car cette adresse IP n'est pas considérée comme "locale".
Il est également possible de **contourner les exigences du réseau local** si vous utilisez **l'adresse IP publique d'un point de terminaison local** (comme l'IP publique du routeur). Car dans plusieurs cas, même si l'**IP publique** est accessible, si c'est **du réseau local**, l'accès sera accordé.
Il a été observé que le paramètre `Access-Control-Allow-Credentials` à **`true`** est un prérequis pour la plupart des **vrais attaques**. Ce paramètre permet au navigateur d'envoyer des informations d'identification et de lire la réponse, augmentant ainsi l'efficacité de l'attaque. Sans cela, l'avantage de faire émettre une requête par un navigateur plutôt que de le faire soi-même diminue, car tirer parti des cookies d'un utilisateur devient irréalisable.
Une exception existe où la localisation réseau de la victime agit comme une forme d'authentification. Cela permet d'utiliser le navigateur de la victime comme un proxy, contournant l'authentification basée sur l'IP pour accéder aux applications intranet. Cette méthode partage des similitudes d'impact avec le DNS rebinding mais est plus simple à exploiter.
Le scénario du monde réel où la valeur de l'en-tête `Origin` est réfléchie dans `Access-Control-Allow-Origin` est théoriquement improbable en raison des restrictions sur la combinaison de ces en-têtes. Cependant, les développeurs cherchant à activer CORS pour plusieurs URL peuvent générer dynamiquement l'en-tête `Access-Control-Allow-Origin` en copiant la valeur de l'en-tête `Origin`. Cette approche peut introduire des vulnérabilités, en particulier lorsqu'un attaquant utilise un domaine avec un nom conçu pour sembler légitime, trompant ainsi la logique de validation.
L'origine `null`, spécifiée pour des situations comme les redirections ou les fichiers HTML locaux, occupe une position unique. Certaines applications ajoutent cette origine à la liste blanche pour faciliter le développement local, permettant involontairement à n'importe quel site web de simuler une origine `null` via une iframe sandboxée, contournant ainsi les restrictions CORS.
Lorsqu'on rencontre une liste blanche de domaines, il est crucial de tester les opportunités de contournement, comme l'ajout du domaine de l'attaquant à un domaine sur liste blanche ou l'exploitation des vulnérabilités de prise de contrôle de sous-domaines. De plus, les expressions régulières utilisées pour la validation des domaines peuvent négliger des nuances dans les conventions de nommage des domaines, présentant ainsi d'autres opportunités de contournement.
Les motifs Regex se concentrent généralement sur les caractères alphanumériques, le point (.) et le tiret (-), négligeant d'autres possibilités. Par exemple, un nom de domaine conçu pour inclure des caractères interprétés différemment par les navigateurs et les motifs regex peut contourner les vérifications de sécurité. La gestion des caractères de soulignement dans les sous-domaines par Safari, Chrome et Firefox illustre comment de telles divergences peuvent être exploitées pour contourner la logique de validation des domaines.
**Pour plus d'informations et de paramètres concernant ce contrôle de contournement :** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **et** [**https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397**](https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397)
Les développeurs mettent souvent en œuvre des mécanismes de défense pour se protéger contre l'exploitation CORS en ajoutant des domaines à la liste blanche qui sont autorisés à demander des informations. Malgré ces précautions, la sécurité du système n'est pas infaillible. La présence même d'un seul sous-domaine vulnérable au sein des domaines sur liste blanche peut ouvrir la porte à l'exploitation CORS par le biais d'autres vulnérabilités, telles que XSS (Cross-Site Scripting).
Pour illustrer, considérons le scénario où un domaine, `requester.com`, est sur liste blanche pour accéder aux ressources d'un autre domaine, `provider.com`. La configuration côté serveur pourrait ressembler à ceci :
Dans cette configuration, tous les sous-domaines de `requester.com` sont autorisés à accéder. Cependant, si un sous-domaine, disons `sub.requester.com`, est compromis avec une vulnérabilité XSS, un attaquant peut exploiter cette faiblesse. Par exemple, un attaquant ayant accès à `sub.requester.com` pourrait exploiter la vulnérabilité XSS pour contourner les politiques CORS et accéder de manière malveillante aux ressources sur `provider.com`.
Il est possible qu'en exploitant le poisonnement de cache côté serveur par injection d'en-tête HTTP, une vulnérabilité XSS stockée puisse être induite. Ce scénario se déroule lorsqu'une application ne parvient pas à assainir l'en-tête `Origin` pour des caractères illégaux, créant une vulnérabilité particulièrement pour les utilisateurs d'Internet Explorer et d'Edge. Ces navigateurs traitent (0x0d) comme un terminateur d'en-tête HTTP légitime, entraînant des vulnérabilités d'injection d'en-tête HTTP.
Bien que l'exploitation directe de cette vulnérabilité en faisant envoyer un en-tête malformé par un navigateur web ne soit pas réalisable, une requête élaborée peut être générée manuellement à l'aide d'outils comme Burp Suite. Cette méthode pourrait conduire à un cache côté serveur enregistrant la réponse et la servant involontairement à d'autres. Le payload élaboré vise à modifier l'ensemble de caractères de la page en UTF-7, un encodage de caractères souvent associé aux vulnérabilités XSS en raison de sa capacité à encoder des caractères d'une manière qui peut être exécutée comme un script dans certains contextes.
**Remarque** : L'exploitation des vulnérabilités d'injection d'en-têtes HTTP, en particulier par le biais du poisoning de cache côté serveur, souligne l'importance critique de valider et de désinfecter toutes les entrées fournies par l'utilisateur, y compris les en-têtes HTTP. Employez toujours un modèle de sécurité robuste qui inclut la validation des entrées pour prévenir de telles vulnérabilités.
Dans ce scénario, une instance d'une page web reflétant le contenu d'un en-tête HTTP personnalisé sans encodage approprié est observée. Plus précisément, la page web renvoie le contenu inclus dans un en-tête `X-User-id`, qui pourrait inclure du JavaScript malveillant, comme le démontre l'exemple où l'en-tête contient une balise d'image SVG conçue pour exécuter du code JavaScript au chargement.
Les politiques de partage de ressources entre origines (CORS) permettent l'envoi d'en-têtes personnalisés. Cependant, sans que la réponse soit directement rendue par le navigateur en raison des restrictions CORS, l'utilité d'une telle injection pourrait sembler limitée. Le point critique se pose lorsque l'on considère le comportement de cache du navigateur. Si l'en-tête `Vary: Origin` n'est pas spécifié, il devient possible que la réponse malveillante soit mise en cache par le navigateur. Par la suite, cette réponse mise en cache pourrait être rendue directement lors de la navigation vers l'URL, contournant ainsi la nécessité d'un rendu direct lors de la requête initiale. Ce mécanisme renforce la fiabilité de l'attaque en tirant parti du cache côté client.
Pour illustrer cette attaque, un exemple de JavaScript est fourni, conçu pour être exécuté dans l'environnement d'une page web, comme à travers un JSFiddle. Ce script effectue une action simple : il envoie une requête à une URL spécifiée avec un en-tête personnalisé contenant le JavaScript malveillant. Une fois la requête réussie, il tente de naviguer vers l'URL cible, déclenchant potentiellement l'exécution du script injecté si la réponse a été mise en cache sans un traitement approprié de l'en-tête `Vary: Origin`.
XSSI, également connu sous le nom de Cross-Site Script Inclusion, est un type de vulnérabilité qui tire parti du fait que la Same Origin Policy (SOP) ne s'applique pas lors de l'inclusion de ressources à l'aide de la balise script. Cela est dû au fait que les scripts doivent pouvoir être inclus depuis différents domaines. Cette vulnérabilité permet à un attaquant d'accéder et de lire tout contenu qui a été inclus à l'aide de la balise script.
Cette vulnérabilité devient particulièrement significative lorsqu'il s'agit de JavaScript dynamique ou de JSONP (JSON avec Padding), surtout lorsque des informations d'autorité ambiante comme les cookies sont utilisées pour l'authentification. Lors de la demande d'une ressource depuis un hôte différent, les cookies sont inclus, les rendant accessibles à l'attaquant.
Pour mieux comprendre et atténuer cette vulnérabilité, vous pouvez utiliser le plugin BurpSuite disponible à [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp). Ce plugin peut aider à identifier et à traiter les vulnérabilités XSSI potentielles dans vos applications web.
Essayez d'ajouter un **`callback`** **paramètre** dans la requête. Peut-être que la page a été préparée pour envoyer les données sous forme de JSONP. Dans ce cas, la page renverra les données avec `Content-Type: application/javascript`, ce qui contournera la politique CORS.
Une façon de contourner la restriction `Access-Control-Allow-Origin` est de demander à une application web de faire une requête en votre nom et de renvoyer la réponse. Cependant, dans ce scénario, les identifiants de la victime finale ne seront pas envoyés car la requête est faite à un domaine différent.
1. [**CORS-escape**](https://github.com/shalvah/cors-escape) : Cet outil fournit un proxy qui transmet votre requête avec ses en-têtes, tout en falsifiant l'en-tête Origin pour correspondre au domaine demandé. Cela contourne effectivement la politique CORS. Voici un exemple d'utilisation avec XMLHttpRequest :
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape) : Cet outil offre une approche alternative pour le proxy des requêtes. Au lieu de transmettre votre requête telle quelle, le serveur effectue sa propre requête avec les paramètres spécifiés.
Vous pouvez **contourner les vérifications CORS** telles que `e.origin === window.origin` en **créant un iframe** et **en ouvrant une nouvelle fenêtre depuis celui-ci**. Plus d'informations sur la page suivante :
Le rebinding DNS via TTL est une technique utilisée pour contourner certaines mesures de sécurité en manipulant les enregistrements DNS. Voici comment cela fonctionne :
1. L'attaquant crée une page web et fait accéder la victime à celle-ci.
2. L'attaquant change ensuite le DNS (IP) de son propre domaine pour pointer vers la page web de la victime.
3. Le navigateur de la victime met en cache la réponse DNS, qui peut avoir une valeur TTL (Time to Live) indiquant combien de temps l'enregistrement DNS doit être considéré comme valide.
4. Lorsque le TTL expire, le navigateur de la victime effectue une nouvelle requête DNS, permettant à l'attaquant d'exécuter du code JavaScript sur la page de la victime.
5. En maintenant le contrôle sur l'IP de la victime, l'attaquant peut recueillir des informations de la victime sans envoyer de cookies au serveur de la victime.
Il est important de noter que les navigateurs ont des mécanismes de mise en cache qui peuvent empêcher l'abus immédiat de cette technique, même avec de faibles valeurs TTL.
Le rebinding DNS peut être utile pour contourner les vérifications IP explicites effectuées par la victime ou pour des scénarios où un utilisateur ou un bot reste sur la même page pendant une période prolongée, permettant à la cache d'expirer.
Si vous avez besoin d'un moyen rapide d'abuser du rebinding DNS, vous pouvez utiliser des services comme [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html).
Pour exécuter votre propre serveur de rebinding DNS, vous pouvez utiliser des outils comme **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)). Cela implique d'exposer votre port local 53/udp, de créer un enregistrement A pointant vers celui-ci (par exemple, ns.example.com), et de créer un enregistrement NS pointant vers le sous-domaine A précédemment créé (par exemple, ns.example.com). Tout sous-domaine du sous-domaine ns.example.com sera alors résolu par votre hôte.
Vous pouvez également explorer un serveur public en cours d'exécution à [http://rebind.it/singularity.html](http://rebind.it/singularity.html) pour une meilleure compréhension et expérimentation.
Le rebinding DNS via le flooding de cache DNS est une autre technique utilisée pour contourner le mécanisme de mise en cache des navigateurs et forcer une seconde requête DNS. Voici comment cela fonctionne :
1. Initialement, lorsque la victime effectue une requête DNS, elle reçoit l'adresse IP de l'attaquant.
2. Pour contourner la défense de mise en cache, l'attaquant utilise un service worker. Le service worker inonde le cache DNS, ce qui supprime effectivement le nom du serveur de l'attaquant mis en cache.
3. Lorsque le navigateur de la victime effectue une seconde requête DNS, il reçoit maintenant l'adresse IP 127.0.0.1, qui fait généralement référence à l'hôte local.
En inondant le cache DNS avec le service worker, l'attaquant peut manipuler le processus de résolution DNS et forcer le navigateur de la victime à effectuer une seconde requête, cette fois-ci résolvant à l'adresse IP souhaitée par l'attaquant.
Une autre façon de contourner la défense de mise en cache est d'utiliser plusieurs adresses IP pour le même sous-domaine dans le fournisseur DNS. Voici comment cela fonctionne :
1. L'attaquant configure deux enregistrements A (ou un seul enregistrement A avec deux IP) pour le même sous-domaine dans le fournisseur DNS.
2. Lorsque le navigateur vérifie ces enregistrements, il reçoit les deux adresses IP.
3. Si le navigateur décide d'utiliser d'abord l'adresse IP de l'attaquant, l'attaquant peut servir une charge utile qui effectue des requêtes HTTP vers le même domaine.
5. Le navigateur de la victime, réalisant que le domaine ne répond pas, passe à utiliser la seconde adresse IP donnée.
6. En accédant à la seconde adresse IP, le navigateur contourne la Same Origin Policy (SOP), permettant à l'attaquant d'abuser de cela et de recueillir et exfiltrer des informations.
Cette technique exploite le comportement des navigateurs lorsque plusieurs adresses IP sont fournies pour un domaine. En contrôlant stratégiquement les réponses et en manipulant le choix de l'adresse IP par le navigateur, un attaquant peut exploiter la SOP et accéder aux informations de la victime.
Notez que pour accéder à localhost, vous devriez essayer de rebind **127.0.0.1** sous Windows et **0.0.0.0** sous Linux.\
Des fournisseurs tels que godaddy ou cloudflare ne m'ont pas permis d'utiliser l'IP 0.0.0.0, mais AWS route53 m'a permis de créer un enregistrement A avec 2 IP, l'une d'elles étant "0.0.0.0"
* Si **les IP internes ne sont pas autorisées**, ils pourraient **oublier d'interdire 0.0.0.0** (fonctionne sous Linux et Mac)
* Si **les IP internes ne sont pas autorisées**, répondez avec un **CNAME** vers **localhost** (fonctionne sous Linux et Mac)
* Si **les IP internes ne sont pas autorisées** en tant que réponses DNS, vous pouvez répondre avec des **CNAMEs vers des services internes** tels que www.corporate.internal.
Vous pouvez trouver plus d'informations sur les techniques de contournement précédentes et comment utiliser l'outil suivant dans la présentation [Gerald Doussot - État des attaques de rebinding DNS & Singularité de l'origine - Conférence DEF CON 27](https://www.youtube.com/watch?v=y9-0lICNjOQ).
[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) est un outil pour effectuer des attaques de [rebinding DNS](https://en.wikipedia.org/wiki/DNS\_rebinding). Il comprend les composants nécessaires pour rebind l'adresse IP du nom DNS du serveur d'attaque à l'adresse IP de la machine cible et pour servir des charges utiles d'attaque afin d'exploiter des logiciels vulnérables sur la machine cible.
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/) : Proposition d'envoyer toujours une requête préliminaire lorsque des serveurs publics souhaitent accéder à des serveurs internes
Apprenez et pratiquez le hacking AWS :<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Apprenez et pratiquez le hacking GCP : <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Consultez les [**plans d'abonnement**](https://github.com/sponsors/carlospolop) !
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez-nous sur****Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Partagez des astuces de hacking en soumettant des PR au** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) dépôts GitHub.
