CORS - Misconfigurations & Bypass
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Šta je CORS?
Cross-Origin Resource Sharing (CORS) standard omogućava serverima da definišu ko može da pristupi njihovim resursima i koje HTTP metode zahteva su dozvoljene iz spoljašnjih izvora.
Politika istog porekla 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 istog domena i porta imaju dozvolu za pristup resursima.
Primena politike istog porekla u kontekstu http://normal-website.com/example/example.html
ilustrovana je na sledeći način:
URL pristupljen | Da li je pristup dozvoljen? |
---|---|
| Da: Identičan shema, domen i port |
| Da: Identičan shema, domen i port |
| Ne: Drugačija shema i port |
| Ne: Drugačiji domen |
| Ne: Drugačiji domen |
| Ne: Drugi port* |
*Internet Explorer zanemaruje broj porta prilikom primene politike istog porekla, čime omogućava ovaj pristup.
Access-Control-Allow-Origin
Header
Access-Control-Allow-Origin
HeaderOvaj header može dozvoliti više porekla, null
vrednost, ili wildcard *
. Međutim, nijedan pretraživač ne podržava više porekla, a korišćenje wildcard *
podložno je ograničenjima. (Wildcard mora biti korišćen samostalno, a njegovo korišćenje zajedno sa Access-Control-Allow-Credentials: true
nije dozvoljeno.)
Ovaj header je izdat od strane servera kao odgovor na zahtev za resursom iz drugog domena koji je pokrenut od strane web stranice, pri čemu pretraživač automatski dodaje Origin
header.
Access-Control-Allow-Credentials
Header
Access-Control-Allow-Credentials
HeaderPo default-u, zahtevi iz drugog porekla se šalju bez kredencijala kao što su kolačići ili Authorization header. Ipak, server iz drugog domena može dozvoliti čitanje odgovora kada su kredencijali poslati 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).
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 se utvrdila 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).
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
:
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:
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
: Ova zaglavlja 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
: Ova zaglavlja, takođe korišćena u pre-flight zahtevima, postavlja klijent da označi koji HTTP metod će biti korišćen u stvarnom zahtevu.Origin
: Ova zaglavlja 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
Access-Control-Request-Local-Network
: Ova zaglavlja se uključuje 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.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 kontrolisan pristup uz održavanje sigurnosnih protokola.
Validan odgovor koji dozvoljava zahtev lokalne mreže takođe treba da ima u odgovoru zaglavlje Access-Controls-Allow-Local_network: true
:
Napomena da linux 0.0.0.0 IP radi za 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.
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 pretraživaču da šalje akreditive i čita odgovor, povećavajući efikasnost napada. Bez toga, korist od slanja zahteva putem pretraživač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 pretraživača žrtve kao proxy, zaobilaženje autentifikacije zasnovane na IP-u za pristup intranet aplikacijama. Ova metoda deli sličnosti u uticaju sa DNS rebinding-om, ali je jednostavnija za iskorišćavanje.
Odsijavanje Origin
u Access-Control-Allow-Origin
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 Access-Control-Allow-Origin
zaglavlje kopirajući vrednost Origin
zaglavlja. Ovaj pristup može uvesti ranjivosti, posebno kada napadač koristi domen sa imenom koje deluje legitimno, obmanjujući logiku validacije.
Iskorišćavanje null
porekla
null
poreklanull
poreklo, određeno za situacije kao što su preusmeravanja ili lokalne HTML datoteke, ima 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-ovanog iframe-a, čime se zaobilaze CORS ograničenja.
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 korišćeni 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 tumače drugačije može zaobići bezbednosne provere. Kako Safari, Chrome i Firefox obrađuju karaktere donje crte u poddomenima 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/ i https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397
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:
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
.
Trovanje keša na serverskoj strani
Moguće je da se iskorišćavanjem trovanja keša na serverskoj strani putem injekcije HTTP header-a može izazvati pohranjena Cross-Site Scripting (XSS) ranjivost. Ovaj scenario se odvija kada aplikacija ne uspe da sanitizuje Origin
header od nelegalnih karaktera, stvarajući ranjivost posebno za korisnike Internet Explorer-a 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:
Internet Explorer i Edge interpretiraju odgovor kao:
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 poput 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 može biti izvršen kao skripta u određenim kontekstima.
Za dalju literaturu o pohranjenim XSS ranjivostima, pogledajte PortSwigger.
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
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 za sliku dizajniran da izvrši JavaScript kod prilikom učitavanja.
Cross-Origin Resource Sharing (CORS) politike omogućavaju slanje prilagođenih zaglavlja. Međutim, bez toga da odgovor bude direktno prikazan od strane pretraživača zbog CORS ograničenja, korisnost takve injekcije može delovati ograničeno. Kritič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 prikazan prilikom navigacije na URL, zaobilazeći potrebu za direktnim prikazivanjem prilikom inicijalnog zahteva. Ovaj mehanizam poboljšava pouzdanost napada korišćenjem keširanja na klijentskoj strani.
Da ilustruje ovaj napad, pružen je JavaScript primer, 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:
Bypass
XSSI (Cross-Site Script Inclusion) / JSONP
XSSI, poznat i 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. 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.
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.
Laka (beskorisna?) zaobilaženja
Jedan od načina da se zaobiđe ograničenje Access-Control-Allow-Origin
je da se zatraži 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.
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:
simple-cors-escape: Ovaj alat nudi alternativni pristup proxy-ju zahteva. Umesto da prosledi vaš zahtev onako kako jeste, server pravi svoj zahtev sa specificiranim parametrima.
Iframe + Popup zaobilaženje
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:
DNS Rebinding putem 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:
Napadač kreira web stranicu i navodi žrtvu da joj pristupi.
Napadač zatim menja DNS (IP) svog domena da ukazuje na web stranicu žrtve.
Pregledač žrtve kešira DNS odgovor, koji može imati TTL (Time to Live) vrednost koja označava koliko dugo se DNS zapis treba smatrati važećim.
Kada TTL istekne, pregledač žrtve pravi novi DNS zahtev, omogućavajući napadaču da izvrši JavaScript kod na stranici žrtve.
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.
Da biste pokrenuli svoj DNS rebinding server, možete koristiti alate kao što su 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 poddomena će tada biti rešen od strane vašeg hosta.
Možete takođe istražiti javno pokrenuti server na http://rebind.it/singularity.html za dalju razumevanje i eksperimentisanje.
DNS Rebinding putem 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 drugog DNS zahteva. Evo kako to funkcioniše:
U početku, kada žrtva napravi DNS zahtev, odgovara se sa IP adresom napadača.
Da bi zaobišao mehanizam keširanja, napadač koristi servisnog radnika. Servisni radnik poplavljuje DNS keš, što efikasno briše keširano ime servera napadača.
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 putem Keša
Još jedan način da se zaobiđe mehanizam keširanja je korišćenjem više IP adresa za isti poddomen kod DNS provajdera. Evo kako to funkcioniše:
Napadač postavlja dva A zapisa (ili jedan A zapis sa dve IP adrese) za isti poddomen kod DNS provajdera.
Kada pregledač proverava ove zapise, prima obe IP adrese.
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.
Međutim, kada napadač dobije IP adresu žrtve, prestaje da odgovara pregledaču žrtve.
Pregledač žrtve, shvativši da domen nije odgovoran, prelazi na korišćenje druge date IP adrese.
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 manipulisanjem izbora IP adrese od strane pregledača, napadač može iskoristiti SOP i pristupiti informacijama od žrtve.
Napomena 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"
Za više informacija možete proveriti https://unit42.paloaltonetworks.com/dns-rebinding/
Druge uobičajene zaobilaženja
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.
Singularity of Origin
je alat za izvođenje 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 za iskorišćavanje ranjivog softvera na ciljnoj mašini.
Prava zaštita od DNS Rebinding
Koristite TLS u internim servisima
Zahtevajte autentifikaciju za pristup podacima
Validirajte Host zaglavlje
https://wicg.github.io/private-network-access/: Predlog da se uvek šalje pre-flight zahtev kada javni serveri žele da pristupe internim serverima
Alati
Fuzz moguće pogrešne konfiguracije u CORS politikama
Reference
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Last updated