# CSRF (Cross Site Request Forgery)
जानें AWS हैकिंग को शून्य से हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ! HackTricks का समर्थन करने के अन्य तरीके: * अगर आप चाहते हैं कि आपकी **कंपनी HackTricks में विज्ञापित हो** या **HackTricks को PDF में डाउनलोड करें** तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें! * [**आधिकारिक PEASS & HackTricks स्वैग**](https://peass.creator-spring.com) प्राप्त करें * हमारे विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) कलेक्शन, **The PEASS Family** की खोज करें * **हमारे साथ जुड़ें** 💬 [**डिस्कॉर्ड समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में शामिल हों या हमें **ट्विटर** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)** पर फॉलो** करें। * **अपने हैकिंग ट्रिक्स साझा करें** द्वारा PRs सबमिट करके [**HackTricks**](https://github.com/carlospolop/hacktricks) और [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos में।
[**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) सर्वर में शामिल होकर अनुभवी हैकर्स और बग बाउंटी हंटर्स के साथ संवाद करें! **हैकिंग इंसाइट्स**\ हैकिंग के उत्साह और चुनौतियों में डूबने वाली सामग्री के साथ जुड़ें **रियल-टाइम हैक न्यूज़**\ तेजी से बदलते हैकिंग विश्व के साथ अप-टू-डेट रहें न्यूज़ और इंसाइट्स के माध्यम से **नवीनतम घोषणाएं**\ नवीनतम बग बाउंटी लॉन्च और महत्वपूर्ण प्लेटफॉर्म अपडेट के साथ जागरूक रहें **हमारे साथ जुड़ें** [**Discord**](https://discord.com/invite/N3FrSbmwdy) और आज ही शीर्ष हैकर्स के साथ सहयोग करना शुरू करें! ## Cross-Site Request Forgery (CSRF) Explained **Cross-Site Request Forgery (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)। * **उपयोगकर्ता सत्यापन**: उपयोगकर्ता के पासवर्ड पूछना या कैप्चा हल करना उपयोगकर्ता की इच्छा की पुष्टि कर सकता है। * **रेफरर या उत्पत्ति हेडर्स की जांच**: इन हेडर्स की मान्यता सत्यापित करने से अनुरोधों का आना विश्वसनीय स्रोतों से होने की मदद मिल सकती है। हालांकि, URL के सावधानीपूर्वक तैयार किए जाने से अच्छे से लागू नहीं होने वाले जांचों को दूर किया जा सकता है, जैसे: * `http://mal.net?orig=http://example.com` (URL विश्वसनीय URL के साथ समाप्त होता है) * `http://example.com.mal.net` (URL विश्वसनीय URL से शुरू होता है) * **पैरामीटर नामों को संशोधित करना**: POST या GET अनुरोधों में पैरामीटरों के नामों को बदलने से स्वचालित हमलों को रोकने में मदद मिल सकती है। * **CSRF टोकन**: प्रत्येक सत्र में एक अद्वितीय CSRF टोकन शामिल करना और इस टोकन की आवश्यकता को आगे के अनुरोधों में आवश्यक करने से CSRF का जोखिम काफी कम हो सकता है। टोकन की प्रभावकारिता को CORS का पालन करके बढ़ाया जा सकता है। इन रक्षाओं को समझना और लागू करना वेब एप्लिकेशनों की सुरक्षा और अखंडता बनाए रखने के लिए महत्वपूर्ण है। ## रक्षाओं को छलना ### POST से GET तक शायद आपको उपयोग करना चाहिए कि **POST अनुरोध भेजने के लिए तैयार है जिसमें एक CSRF टोकन है**, लेकिन, आपको **जांचना** चाहिए कि क्या एक **GET** भी **मान्य** है और यदि जब आप एक GET अनुरोध भेजते हैं तो **CSRF टोकन अब भी मान्य है** या नहीं। ### टोकन की कमी एप्लिकेशनें शायद टोकनों को **मान्य करने के लिए एक तंत्र** लागू कर सकती हैं जब वे मौजूद होते हैं। हालांकि, एक सुरक्षा दोष उत्पन्न होता है अगर जब टोकन अनुपस्थित होता है तो मान्यता को पारित किया जाता है। हमलावादी इसे उस पैरामीटर को हटा कर उसके मान को नहीं, बल्कि उसके मूल्य को हटाकर इसका उपयो ```html
``` {% hint style="info" %} ध्यान दें कि यदि **csrf टोकन सत्र कुकी से संबंधित है तो यह हमला काम नहीं करेगा** क्योंकि आपको पीड़ित को अपना सत्र सेट करने की आवश्यकता होगी, और इसलिए आप खुद पर हमला कर रहे होंगे। {% endhint %} ### Content-Type बदलें [**इस**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests) के अनुसार **प्रीफ्लाइट** अनुरोधों से बचने के लिए **POST** विधि का उपयोग करते समय ये स्वीकृत Content-Type मान हैं: * **`application/x-www-form-urlencoded`** * **`multipart/form-data`** * **`text/plain`** हालांकि, ध्यान दें कि **सर्वर का तर्क भिन्न हो सकता है** जिसका आधार **Content-Type** पर है इसलिए आपको उल्लिखित मानों को और जैसे **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ जैसे अन्य मानों का प्रयास करना चाहिए। उदाहरण (यहाँ से) JSON डेटा को text/plain के रूप में भेजने का: ```html
``` ### प्रीफ्लाइट अनुरोधों को जेएसओएन डेटा के लिए बाईपास करना जब पोस्ट अनुरोध के माध्यम से जेएसओएन डेटा भेजने का प्रयास किया जाता है, तो HTML फॉर्म में `Content-Type: application/json` का सीधा उपयोग संभाव नहीं है। इसी तरह, इस सामग्री प्रकार को भेजने के लिए `XMLHttpRequest` का उपयोग करना एक प्रीफ्लाइट अनुरोध प्रारंभ करता है। फिर भी, इस सीमा को उम्मीदवार बाईपास करने के लिए और यह जांचने के लिए कि सर्वर जेएसओएन डेटा को Content-Type के बावजूद प्रसंस्करण करता है, कुछ रणनीतियाँ हैं: 1. **वैकल्पिक सामग्री प्रकार का उपयोग करें**: फॉर्म में `enctype="text/plain"` सेट करके `Content-Type: text/plain` या `Content-Type: application/x-www-form-urlencoded` का उपयोग करें। यह दृष्टिकोण परीक्षण करता है कि पीछे की ओर डेटा का उपयोग करता है या नहीं, Content-Type के बावजूद। 2. **सामग्री प्रकार में परिवर्तन करें**: प्रीफ्लाइट अनुरोध से बचने के लिए साथ ही सर्वर को सामग्री को जेएसओएन के रूप में मान्यता प्रदान करने के लिए, आप `Content-Type: text/plain; application/json` के साथ डेटा भेज सकते हैं। यह एक प्रीफ्लाइट अनुरोध को ट्रिगर नहीं करता है लेकिन यदि सर्वर `application/json` स्वीकार करने के लिए कॉन्फ़िगर किया गया है तो सही ढंग से प्रसंस्कृत हो सकता है। 3. **एसडब्ल्यूएफ फ्लैश फ़ाइल उपयोग**: एक कम प्रचलित लेकिन संभावनाशील विधि शामिल है जिसमें ऐसी प्रतिबंधों को बाईपास करने के लिए एसडब्ल्यूएफ फ्लैश फ़ाइल का उपयोग किया जाता है। इस तकनीक की गहन समझ के लिए, [इस पोस्ट](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937) का संदर्भ देखें। ### रेफरर / उत्पत्ति जांच बाईपास **रेफरर हेडर से बचें** एप्लिकेशन्स केवल तब 'Referer' हेडर को मान्यता देते हैं जब यह मौजूद होता है। इस हेडर को ब्राउज़र से भेजने से रोकने के लिए, निम्नलिखित HTML मेटा टैग का उपयोग किया जा सकता है: ```xml ``` यह सुनिश्चित करता है कि 'Referer' हेडर छोड़ दिया जाता है, कुछ एप्लिकेशन में मान्यता की जांचों को छलने की संभावना है। **रेजेक्स बाईपास** {% content-ref url="ssrf-server-side-request-forgery/url-format-bypass.md" %} [url-format-bypass.md](ssrf-server-side-request-forgery/url-format-bypass.md) {% endcontent-ref %} सर्वर के डोमेन नाम को URL में सेट करने के लिए जिस URL में Referrer पैरामीटर के भीतर भेजा जाएगा, आप यह कर सकते हैं: ```html
``` ### **HEAD method bypass** पहला हिस्सा [**इस 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 रिक्वेस्ट्स के लिए एक विशिष्ट हैंडलर की बजाय, वे **सिर्फ GET हैंडलर को देते हैं लेकिन एप्लिकेशन बस रिस्पॉन्स बॉडी को हटा देता है**। इसलिए, अगर एक GET रिक्वेस्ट पर प्रतिबंध लगाया जा रहा है, तो आप **एक HEAD रिक्वेस्ट भेज सकते हैं जो एक GET रिक्व ```xml

404 - Page not found

The URL you are requesting is no longer available ``` अन्य HTML5 टैग जो स्वचालित रूप से GET अनुरोध भेजने के लिए प्रयोग किए जा सकते हैं: ```html