<summary><strong>जानें AWS हैकिंग को शून्य से हीरो तक</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>
* अगर आप चाहते हैं कि आपकी **कंपनी HackTricks में विज्ञापित हो** या **HackTricks को PDF में डाउनलोड करें** तो [**सब्सक्रिप्शन प्लान्स**](https://github.com/sponsors/carlospolop) देखें!
* हमारे विशेष [**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 में।
**Cross-Site Request Forgery (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)।
* **रेफरर या उत्पत्ति हेडर्स की जांच**: इन हेडर्स की मान्यता सत्यापित करने से अनुरोधों का आना विश्वसनीय स्रोतों से होने की मदद मिल सकती है। हालांकि, URL के सावधानीपूर्वक तैयार किए जाने से अच्छे से लागू नहीं होने वाले जांचों को दूर किया जा सकता है, जैसे:
* **CSRF टोकन**: प्रत्येक सत्र में एक अद्वितीय CSRF टोकन शामिल करना और इस टोकन की आवश्यकता को आगे के अनुरोधों में आवश्यक करने से CSRF का जोखिम काफी कम हो सकता है। टोकन की प्रभावकारिता को CORS का पालन करके बढ़ाया जा सकता है।
शायद आपको उपयोग करना चाहिए कि **POST अनुरोध भेजने के लिए तैयार है जिसमें एक CSRF टोकन है**, लेकिन, आपको **जांचना** चाहिए कि क्या एक **GET** भी **मान्य** है और यदि जब आप एक GET अनुरोध भेजते हैं तो **CSRF टोकन अब भी मान्य है** या नहीं।
एप्लिकेशनें शायद टोकनों को **मान्य करने के लिए एक तंत्र** लागू कर सकती हैं जब वे मौजूद होते हैं। हालांकि, एक सुरक्षा दोष उत्पन्न होता है अगर जब टोकन अनुपस्थित होता है तो मान्यता को पारित किया जाता है। हमलावादी इसे उस पैरामीटर को हटा कर उसके मान को नहीं, बल्कि उसके मूल्य को हटाकर इसका उपयो
ध्यान दें कि यदि **csrf टोकन सत्र कुकी से संबंधित है तो यह हमला काम नहीं करेगा** क्योंकि आपको पीड़ित को अपना सत्र सेट करने की आवश्यकता होगी, और इसलिए आप खुद पर हमला कर रहे होंगे।
[**इस**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests) के अनुसार **प्रीफ्लाइट** अनुरोधों से बचने के लिए **POST** विधि का उपयोग करते समय ये स्वीकृत Content-Type मान हैं:
हालांकि, ध्यान दें कि **सर्वर का तर्क भिन्न हो सकता है** जिसका आधार **Content-Type** पर है इसलिए आपको उल्लिखित मानों को और जैसे **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ जैसे अन्य मानों का प्रयास करना चाहिए।
जब पोस्ट अनुरोध के माध्यम से जेएसओएन डेटा भेजने का प्रयास किया जाता है, तो 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 मेटा टैग का उपयोग किया जा सकता है:
पहला हिस्सा [**इस 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 हैंडलर को देते हैं लेकिन एप्लिकेशन बस रिस्पॉन्स बॉडी को हटा देता है**।
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 टोकन का उपयोग करके लॉगिन फॉर्म को ब्रूट फोर्स करने के लिए किया जा सकता है (यह भी शीर्षक X-Forwarded-For का उपयोग कर रहा है ताकि संभावित आईपी ब्लैकलिस्टिंग को अनदेखा करने का प्रयास करें):
रियल-टाइम समाचार और अंतर्दृष्टि के माध्यम से तेजी से बदलते हैकिंग विश्व के साथ अद्यतन रहें
**नवीनतम घोषणाएं**\
नवीनतम बग बाउंटी लॉन्च और महत्वपूर्ण प्लेटफॉर्म अपडेट के साथ अवगत रहें
[**Discord**](https://discord.com/invite/N3FrSbmwdy) पर हमारे साथ जुड़ें और आज ही शीर्ष हैकर्स के साथ सहयोग करना शुरू करें!
<details>
<summary><strong>शून्य से हीरो तक AWS हैकिंग सीखें</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong> के साथ!</strong></summary>
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)** पर फॉलो** करें।
* **HackTricks** और **HackTricks Cloud** github रेपो में PR जमा करके अपने हैकिंग ट्रिक्स साझा करें।