Learn & practice AWS Hacking:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
**क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF)** एक प्रकार की सुरक्षा कमजोरी है जो वेब अनुप्रयोगों में पाई जाती है। यह हमलावरों को अनजान उपयोगकर्ताओं की ओर से कार्य करने की अनुमति देती है, उनके प्रमाणित सत्रों का लाभ उठाकर। यह हमला तब होता है जब एक उपयोगकर्ता, जो एक पीड़ित के प्लेटफॉर्म में लॉग इन है, एक दुर्भावनापूर्ण साइट पर जाता है। यह साइट फिर पीड़ित के खाते के लिए अनुरोधों को ट्रिगर करती है, जैसे कि जावास्क्रिप्ट को निष्पादित करना, फॉर्म सबमिट करना, या छवियों को लाना।
1.**एक मूल्यवान क्रिया की पहचान करें**: हमलावर को एक ऐसा कार्य खोजना होगा जिसका लाभ उठाया जा सके, जैसे उपयोगकर्ता का पासवर्ड, ईमेल बदलना, या विशेषाधिकार बढ़ाना।
2.**सत्र प्रबंधन**: उपयोगकर्ता का सत्र केवल कुकीज़ या HTTP बेसिक प्रमाणीकरण हेडर के माध्यम से प्रबंधित किया जाना चाहिए, क्योंकि अन्य हेडर का इस उद्देश्य के लिए हेरफेर नहीं किया जा सकता।
3.**अनपेक्षित पैरामीटर का अभाव**: अनुरोध में अनपेक्षित पैरामीटर नहीं होने चाहिए, क्योंकि वे हमले को रोक सकते हैं।
आप **Burp में अनुरोध कैप्चर** कर सकते हैं और CSRF सुरक्षा की जांच कर सकते हैं और ब्राउज़र से परीक्षण करने के लिए आप **Copy as fetch** पर क्लिक कर सकते हैं और अनुरोध की जांच कर सकते हैं:
* [**SameSite कुकीज़**](hacking-with-cookies/#samesite): यह विशेषता ब्राउज़र को क्रॉस-साइट अनुरोधों के साथ कुकीज़ भेजने से रोकती है। [SameSite कुकीज़ के बारे में अधिक जानें](hacking-with-cookies/#samesite)।
* [**क्रॉस-उत्पत्ति संसाधन साझा करना**](cors-bypass.md): पीड़ित साइट की CORS नीति हमले की व्यवहार्यता को प्रभावित कर सकती है, विशेष रूप से यदि हमले को पीड़ित साइट से प्रतिक्रिया पढ़ने की आवश्यकता हो। [CORS बायपास के बारे में जानें](cors-bypass.md)।
* **रेफरर या मूल हेडर की जांच करना**: इन हेडरों को मान्य करना यह सुनिश्चित करने में मदद कर सकता है कि अनुरोध विश्वसनीय स्रोतों से आ रहे हैं। हालाँकि, URLs को सावधानीपूर्वक तैयार करने से खराब तरीके से लागू की गई जांचों को बायपास किया जा सकता है, जैसे:
* **पैरामीटर नामों में संशोधन**: POST या GET अनुरोधों में पैरामीटर के नामों को बदलना स्वचालित हमलों को रोकने में मदद कर सकता है।
* **CSRF टोकन**: प्रत्येक सत्र में एक अद्वितीय CSRF टोकन को शामिल करना और इस टोकन की आवश्यकता करना अगले अनुरोधों में CSRF के जोखिम को काफी कम कर सकता है। टोकन की प्रभावशीलता को CORS को लागू करके बढ़ाया जा सकता है।
शायद जिस फॉर्म का आप दुरुपयोग करना चाहते हैं वह **CSRF टोकन के साथ POST अनुरोध भेजने के लिए तैयार है**, लेकिन आपको **जांचना चाहिए** कि क्या एक **GET** भी **मान्य** है और यदि जब आप GET अनुरोध भेजते हैं तो **CSRF टोकन अभी भी मान्य है**।
अनुप्रयोग एक तंत्र लागू कर सकते हैं **टोकनों को मान्य करने के लिए** जब वे मौजूद होते हैं। हालाँकि, एक कमजोरी तब उत्पन्न होती है जब टोकन के अनुपस्थित होने पर मान्यता पूरी तरह से छोड़ दी जाती है। हमलावर इस पर **टोकन ले जाने वाले पैरामीटर को हटा कर** इसका लाभ उठा सकते हैं, न कि केवल इसके मान को। इससे उन्हें मान्यता प्रक्रिया को बायपास करने और प्रभावी रूप से क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF) हमले को अंजाम देने की अनुमति मिलती है।
अनुप्रयोग **CSRF टोकनों को उपयोगकर्ता सत्रों से नहीं बांधने** पर एक महत्वपूर्ण **सुरक्षा जोखिम** प्रस्तुत करते हैं। ये सिस्टम टोकनों को एक **वैश्विक पूल** के खिलाफ मान्य करते हैं, बजाय इसके कि प्रत्येक टोकन को आरंभिक सत्र से बंधा हो।
यदि अनुरोध एक "**अजीब**" **विधि** का उपयोग कर रहा है, तो जांचें कि क्या **विधि****ओवरराइड कार्यक्षमता** काम कर रही है। उदाहरण के लिए, यदि यह **PUT** विधि का उपयोग कर रहा है, तो आप **POST** विधि का उपयोग करने का प्रयास कर सकते हैं और **भेजें**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
यह **POST अनुरोध के अंदर \_method पैरामीटर** भेजकर या **हेडर** का उपयोग करके भी काम कर सकता है:
अनुप्रयोग CSRF सुरक्षा को टोकन को एक कुकी और एक अनुरोध पैरामीटर में दोहराकर या एक CSRF कुकी सेट करके और यह सत्यापित करके लागू कर सकते हैं कि बैकएंड में भेजा गया टोकन कुकी के अनुरूप है। अनुप्रयोग अनुरोधों को मान्य करता है यह जांचकर कि क्या अनुरोध पैरामीटर में टोकन कुकी में मान के साथ मेल खाता है।
हालांकि, यदि वेबसाइट में ऐसी खामियाँ हैं जो हमलावर को पीड़ित के ब्राउज़र में CSRF कुकी सेट करने की अनुमति देती हैं, जैसे कि CRLF कमजोरी, तो यह विधि CSRF हमलों के प्रति संवेदनशील है। हमलावर इसका लाभ उठाकर एक धोखाधड़ी छवि लोड कर सकता है जो कुकी सेट करती है, इसके बाद CSRF हमले को शुरू कर सकता है।
ध्यान दें कि यदि **csrf टोकन सत्र कुकी से संबंधित है तो यह हमला काम नहीं करेगा** क्योंकि आपको पीड़ित का सत्र सेट करना होगा, और इसलिए आप खुद पर हमला कर रहे होंगे।
[**इस**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests) के अनुसार, **preflight** अनुरोधों से बचने के लिए **POST** विधि का उपयोग करते समय ये अनुमत Content-Type मान हैं:
हालांकि, ध्यान दें कि **सर्वर की लॉजिक भिन्न हो सकती है** उपयोग किए गए **Content-Type** के आधार पर, इसलिए आपको उल्लेखित मानों और अन्य जैसे **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ का प्रयास करना चाहिए।
जब 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 मेटा टैग का उपयोग किया जा सकता है:
[**इस 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 हैंडलर को दिया जाता है लेकिन ऐप बस प्रतिक्रिया शरीर को हटा देता है**।
यदि एक **CSRF टोकन** को **रक्षा** के रूप में उपयोग किया जा रहा है, तो आप एक [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) भेद्यता या [**Dangling Markup**](dangling-markup-html-scriptless-injection/) भेद्यता का दुरुपयोग करके इसे **निकालने** की कोशिश कर सकते हैं।
xh.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); //to send proper header info (optional, but good to have as it may sometimes not work without this)
कोड का उपयोग CSRF टोकन का उपयोग करके एक लॉगिन फॉर्म को ब्रूट फोर्स करने के लिए किया जा सकता है (यह संभावित IP ब्लैकलिस्टिंग को बायपास करने के लिए X-Forwarded-For हेडर का भी उपयोग कर रहा है):
AWS Hacking सीखें और अभ्यास करें:<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="../.gitbook/assets/arte.png"alt=""data-size="line">\
GCP Hacking सीखें और अभ्यास करें: <imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="../.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* [**सदस्यता योजनाएँ**](https://github.com/sponsors/carlospolop) की जांच करें!
* **💬 [**Discord समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में शामिल हों या **Twitter** 🐦 पर हमें **फॉलो** करें [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **हैकिंग ट्रिक्स साझा करें और** [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) गिटहब रिपोजिटरी में PR सबमिट करें।