CSRF (Cross Site Request Forgery)
Join HackenProof Discord server to communicate with experienced hackers and bug bounty hunters!
Hacking Insights Engage with content that delves into the thrill and challenges of hacking
Real-Time Hack News Keep up-to-date with fast-paced hacking world through real-time news and insights
Latest Announcements Stay informed with the newest bug bounties launching and crucial platform updates
Join us on Discord and start collaborating with top hackers today!
Cross-Site Request Forgery (CSRF) Explained
Cross-Site Request Forgery (CSRF) एक प्रकार की सुरक्षा कमजोरी है जो वेब अनुप्रयोगों में पाई जाती है। यह हमलावरों को अनजान उपयोगकर्ताओं की ओर से कार्य करने की अनुमति देती है, उनके प्रमाणित सत्रों का लाभ उठाकर। यह हमला तब होता है जब एक उपयोगकर्ता, जो किसी पीड़ित के प्लेटफॉर्म में लॉग इन है, एक दुर्भावनापूर्ण साइट पर जाता है। यह साइट फिर पीड़ित के खाते के लिए अनुरोधों को ट्रिगर करती है, जैसे कि जावास्क्रिप्ट को निष्पादित करना, फॉर्म सबमिट करना, या छवियों को लाना।
Prerequisites for a CSRF Attack
CSRF कमजोरी का लाभ उठाने के लिए, कई शर्तें पूरी होनी चाहिए:
एक मूल्यवान क्रिया की पहचान करें: हमलावर को एक ऐसा कार्य खोजना होगा जिसका लाभ उठाया जा सके, जैसे उपयोगकर्ता का पासवर्ड, ईमेल बदलना, या विशेषाधिकार बढ़ाना।
सत्र प्रबंधन: उपयोगकर्ता का सत्र केवल कुकीज़ या HTTP बेसिक प्रमाणीकरण हेडर के माध्यम से प्रबंधित किया जाना चाहिए, क्योंकि अन्य हेडर का इस उद्देश्य के लिए हेरफेर नहीं किया जा सकता।
अनपेक्षित पैरामीटर का अभाव: अनुरोध में अनपेक्षित पैरामीटर नहीं होने चाहिए, क्योंकि वे हमले को रोक सकते हैं।
Quick Check
आप Burp में अनुरोध को कैप्चर कर सकते हैं और CSRF सुरक्षा की जांच कर सकते हैं और ब्राउज़र से परीक्षण करने के लिए आप Copy as fetch पर क्लिक कर सकते हैं और अनुरोध की जांच कर सकते हैं:
Defending Against CSRF
CSRF हमलों से बचाने के लिए कई प्रतिकूल उपाय लागू किए जा सकते हैं:
SameSite कुकीज़: यह विशेषता ब्राउज़र को क्रॉस-साइट अनुरोधों के साथ कुकीज़ भेजने से रोकती है। SameSite कुकीज़ के बारे में अधिक जानें।
क्रॉस-ओरिजिन रिसोर्स शेयरिंग: पीड़ित साइट की CORS नीति हमले की व्यवहार्यता को प्रभावित कर सकती है, विशेष रूप से यदि हमले को पीड़ित साइट से प्रतिक्रिया पढ़ने की आवश्यकता हो। CORS बायपास के बारे में जानें।
उपयोगकर्ता सत्यापन: उपयोगकर्ता का पासवर्ड मांगना या कैप्चा हल करना उपयोगकर्ता की मंशा की पुष्टि कर सकता है।
रेफरर या ओरिजिन हेडर की जांच करना: इन हेडरों को मान्य करना यह सुनिश्चित करने में मदद कर सकता है कि अनुरोध विश्वसनीय स्रोतों से आ रहे हैं। हालाँकि, URLs को सावधानीपूर्वक तैयार करने से खराब तरीके से लागू की गई जांचों को बायपास किया जा सकता है, जैसे:
http://mal.net?orig=http://example.com
का उपयोग करना (URL विश्वसनीय URL के साथ समाप्त होता है)http://example.com.mal.net
का उपयोग करना (URL विश्वसनीय URL के साथ शुरू होता है)पैरामीटर नामों में परिवर्तन: POST या GET अनुरोधों में पैरामीटर के नामों को बदलना स्वचालित हमलों को रोकने में मदद कर सकता है।
CSRF टोकन: प्रत्येक सत्र में एक अद्वितीय CSRF टोकन को शामिल करना और इस टोकन की आवश्यकता को अगले अनुरोधों में रखना CSRF के जोखिम को काफी कम कर सकता है। टोकन की प्रभावशीलता को CORS को लागू करके बढ़ाया जा सकता है।
इन सुरक्षा उपायों को समझना और लागू करना वेब अनुप्रयोगों की सुरक्षा और अखंडता बनाए रखने के लिए महत्वपूर्ण है।
Defences Bypass
From POST to GET
शायद जिस फॉर्म का आप दुरुपयोग करना चाहते हैं वह CSRF टोकन के साथ POST अनुरोध भेजने के लिए तैयार है, लेकिन आपको जांचना चाहिए कि क्या एक GET भी मान्य है और यदि जब आप GET अनुरोध भेजते हैं तो CSRF टोकन अभी भी मान्य है।
Lack of token
अनुप्रयोग एक तंत्र को लागू कर सकते हैं ताकि टोकन की वैधता की जांच की जा सके जब वे मौजूद हों। हालाँकि, एक कमजोरी तब उत्पन्न होती है जब टोकन के अनुपस्थित होने पर मान्यता पूरी तरह से छोड़ दी जाती है। हमलावर इस पर टोकन ले जाने वाले पैरामीटर को हटा कर लाभ उठा सकते हैं, न कि केवल इसके मान को। इससे उन्हें मान्यता प्रक्रिया को बायपास करने और प्रभावी रूप से एक क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF) हमला करने की अनुमति मिलती है।
CSRF token is not tied to the user session
अनुप्रयोग CSRF टोकनों को उपयोगकर्ता सत्रों से नहीं जोड़ने पर एक महत्वपूर्ण सुरक्षा जोखिम प्रस्तुत करते हैं। ये सिस्टम टोकनों को एक वैश्विक पूल के खिलाफ मान्य करते हैं, बजाय इसके कि प्रत्येक टोकन को आरंभिक सत्र से बंधा हुआ सुनिश्चित किया जाए।
हमलावर इस तरह से लाभ उठाते हैं:
अपने खाते का उपयोग करके प्रमाणीकरण करें।
वैध CSRF टोकन प्राप्त करें वैश्विक पूल से।
इस टोकन का उपयोग करें एक CSRF हमले में पीड़ित के खिलाफ।
यह कमजोरी हमलावरों को पीड़ित की ओर से अनधिकृत अनुरोध करने की अनुमति देती है, अनुप्रयोग की अपर्याप्त टोकन मान्यता तंत्र का लाभ उठाते हुए।
Method bypass
यदि अनुरोध एक "अजीब" विधि का उपयोग कर रहा है, तो जांचें कि क्या विधि ओवरराइड कार्यक्षमता काम कर रही है। उदाहरण के लिए, यदि यह PUT विधि का उपयोग कर रहा है, तो आप POST विधि का उपयोग करने का प्रयास कर सकते हैं और भेजें: https://example.com/my/dear/api/val/num?_method=PUT
यह POST अनुरोध के अंदर _method पैरामीटर भेजकर या हेडर का उपयोग करके भी काम कर सकता है:
X-HTTP-Method
X-HTTP-Method-Override
X-Method-Override
Custom header token bypass
यदि अनुरोध एक कस्टम हेडर के साथ एक टोकन जोड़ रहा है जिसे CSRF सुरक्षा विधि के रूप में उपयोग किया जा रहा है, तो:
कस्टमाइज्ड टोकन और हेडर के बिना अनुरोध का परीक्षण करें।
सटीक समान लंबाई लेकिन अलग टोकन के साथ अनुरोध का परीक्षण करें।
CSRF token is verified by a cookie
अनुप्रयोग CSRF सुरक्षा को टोकन को कुकी और अनुरोध पैरामीटर दोनों में डुप्लिकेट करके या एक CSRF कुकी सेट करके और यह सत्यापित करके लागू कर सकते हैं कि बैकएंड में भेजा गया टोकन कुकी के अनुरूप है। अनुप्रयोग अनुरोधों को मान्य करता है यह जांचकर कि क्या अनुरोध पैरामीटर में टोकन कुकी में मान के साथ मेल खाता है।
हालांकि, यदि वेबसाइट में ऐसे दोष हैं जो हमलावर को पीड़ित के ब्राउज़र में CSRF कुकी सेट करने की अनुमति देते हैं, जैसे कि CRLF कमजोरी, तो यह विधि CSRF हमलों के प्रति संवेदनशील है। हमलावर इस पर लाभ उठा सकते हैं एक धोखाधड़ी छवि लोड करके जो कुकी सेट करती है, इसके बाद CSRF हमले को शुरू करती है।
नीचे एक उदाहरण है कि एक हमला कैसे संरचित किया जा सकता है:
ध्यान दें कि यदि csrf टोकन सत्र कुकी से संबंधित है तो यह हमला काम नहीं करेगा क्योंकि आपको पीड़ित का सत्र सेट करना होगा, और इसलिए आप खुद पर हमला कर रहे होंगे।
Content-Type परिवर्तन
इस के अनुसार, preflight अनुरोधों से बचने के लिए POST विधि का उपयोग करते समय ये अनुमत Content-Type मान हैं:
application/x-www-form-urlencoded
multipart/form-data
text/plain
हालांकि, ध्यान दें कि सर्वर की लॉजिक भिन्न हो सकती है जो Content-Type के उपयोग पर निर्भर करती है, इसलिए आपको उल्लेखित मानों और अन्य जैसे application/json
,text/xml
, application/xml
. को आजमाना चाहिए।
उदाहरण ( यहां से) JSON डेटा को text/plain के रूप में भेजने का:
JSON डेटा के लिए प्रीफ्लाइट अनुरोधों को बायपास करना
जब POST अनुरोध के माध्यम से JSON डेटा भेजने का प्रयास किया जाता है, तो HTML फॉर्म में Content-Type: application/json
का उपयोग सीधे संभव नहीं है। इसी तरह, इस सामग्री प्रकार को भेजने के लिए XMLHttpRequest
का उपयोग करने से एक प्रीफ्लाइट अनुरोध शुरू होता है। फिर भी, इस सीमा को बायपास करने और यह जांचने के लिए रणनीतियाँ हैं कि क्या सर्वर सामग्री प्रकार की परवाह किए बिना JSON डेटा को संसाधित करता है:
वैकल्पिक सामग्री प्रकार का उपयोग करें: फॉर्म में
enctype="text/plain"
सेट करकेContent-Type: text/plain
याContent-Type: application/x-www-form-urlencoded
का उपयोग करें। यह दृष्टिकोण परीक्षण करता है कि क्या बैकएंड डेटा का उपयोग करता है चाहे सामग्री प्रकार कुछ भी हो।सामग्री प्रकार को संशोधित करें: प्रीफ्लाइट अनुरोध से बचने के लिए जबकि यह सुनिश्चित करते हुए कि सर्वर सामग्री को JSON के रूप में पहचानता है, आप डेटा को
Content-Type: text/plain; application/json
के साथ भेज सकते हैं। यह प्रीफ्लाइट अनुरोध को ट्रिगर नहीं करता है लेकिन यदि सर्वर कोapplication/json
स्वीकार करने के लिए कॉन्फ़िगर किया गया है तो इसे सही ढंग से संसाधित किया जा सकता है।SWF फ्लैश फ़ाइल का उपयोग: एक कम सामान्य लेकिन संभव विधि में ऐसे प्रतिबंधों को बायपास करने के लिए SWF फ्लैश फ़ाइल का उपयोग करना शामिल है। इस तकनीक की गहन समझ के लिए, इस पोस्ट को देखें।
रेफरर / मूल जांच बायपास
रेफरर हेडर से बचें
ऐप्लिकेशन केवल तब 'Referer' हेडर को मान्य कर सकते हैं जब यह मौजूद हो। इस हेडर को भेजने से रोकने के लिए, निम्नलिखित HTML मेटा टैग का उपयोग किया जा सकता है:
यह सुनिश्चित करता है कि 'Referer' हेडर को छोड़ दिया गया है, जिससे कुछ अनुप्रयोगों में मान्यता जांचों को बायपास किया जा सकता है।
Regexp बायपास
URL Format BypassReferrer द्वारा भेजे जाने वाले पैरामीटर के अंदर URL में सर्वर का डोमेन नाम सेट करने के लिए आप कर सकते हैं:
HEAD विधि बायपास
इस CTF लेख के पहले भाग में समझाया गया है कि Oak का स्रोत कोड, एक राउटर को HEAD अनुरोधों को GET अनुरोधों के रूप में संभालने के लिए सेट किया गया है जिसमें कोई प्रतिक्रिया शरीर नहीं है - एक सामान्य समाधान जो Oak के लिए अद्वितीय नहीं है। HEAD reqs से निपटने के लिए एक विशिष्ट हैंडलर के बजाय, उन्हें बस GET हैंडलर को दिया जाता है लेकिन ऐप बस प्रतिक्रिया शरीर को हटा देता है।
इसलिए, यदि GET अनुरोध को सीमित किया जा रहा है, तो आप बस एक HEAD अनुरोध भेज सकते हैं जिसे GET अनुरोध के रूप में संसाधित किया जाएगा।
शोषण उदाहरण
CSRF टोकन निकालना
यदि CSRF टोकन को रक्षा के रूप में उपयोग किया जा रहा है, तो आप इसे निकालने के लिए XSS भेद्यता या Dangling Markup भेद्यता का दुरुपयोग करने की कोशिश कर सकते हैं।
HTML टैग का उपयोग करके GET
अन्य HTML5 टैग जो स्वचालित रूप से GET अनुरोध भेजने के लिए उपयोग किए जा सकते हैं: