👋🏽 😳 👩🏽‍🏭 सुरक्षा क्रिब: सीएसआरएफ 🧝🏿 👨🏼‍⚕️ 😵

इस तथ्य के बावजूद कि ओडब्ल्यूएएसपी शीर्ष 10 2017 की कमजोरियों की अंतिम प्रकाशित सूची में सीएसआरएफ हमलों को "हटाए गए, लेकिन भुलाए नहीं" के रूप में वर्गीकृत किया गया है, हमने फैसला किया कि यह एक बार फिर से याद नहीं होगा कि सीएसएफएफ हमलों के खिलाफ कैसे बचाव किया जाए। OWASP द्वारा प्रदान किए गए समान नियम।

CSRF टोकन का उपयोग करना

एक टोकन का उपयोग करना (दोनों स्टेटलेस और स्टेटफुल तरीकों) सुरक्षा का प्राथमिक और सबसे लोकप्रिय तरीका है। प्रत्येक उपयोगकर्ता सत्र के लिए टोकन अद्वितीय होना चाहिए, जो क्रिप्टोग्राफिक रूप से मजबूत छद्म यादृच्छिक संख्या जनरेटर द्वारा उत्पन्न होता है। OWASP HMAC का उपयोग करते समय एन्क्रिप्शन के लिए AES256-GCM और SHA256 / 512 एल्गोरिदम का उपयोग करने की भी सिफारिश करता है।

टोकन के साथ काम करने के लिए कई दृष्टिकोण हैं: सिंक्रोनाइज़र टोकन, एन्क्रिप्शन आधारित टोकन पैटर्न, एचएमएसी आधारित टोकन

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

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

<form action="/post.php" method="post"> <input type="hidden" name="CSRFToken" value="l5824xNMAYFesBxing975yR8HPJlHZ"> ... </form>

हेडर में:

 POST /page HTTP/1.1 Accept: application/json, application/xml, text/json, text/x-json, text/javascript, text/xml User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36 Content-Type: application/json Host: example.com X-CSRF-TOKEN: l5824xNMAYFesBxing975yR8HPJlHZ

या कुकीज़ में

 POST /page HTTP/1.1 Host: example.com Set-Cookie: CSRFToken=l5824xNMAYFesBxing975yR8HPJlHZ; Content-Type: application/x-www-form-urlencoded

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

इसके अलावा, प्रस्तावित विधि के सुरक्षा स्तर को बढ़ाने के लिए, प्रत्येक अनुरोध पर एक यादृच्छिक टोकन पैरामीटर नाम और / या टोकन स्वयं उत्पन्न करना प्रस्तावित है। इस दृष्टिकोण के साथ, जिस समय के दौरान हमलावर चोरी किए गए टोकन का उपयोग कर सकता है वह न्यूनतम है। हालांकि, यह प्रयोज्य मुद्दों को जन्म दे सकता है। उदाहरण के लिए, "बैक" बटन पर क्लिक करने से सर्वर को अमान्य टोकन भेजा जा सकता है, जो पिछले पृष्ठ पर निहित था।

GET अनुरोध का उपयोग करके टोकन भेजना अनुशंसित नहीं है, क्योंकि इस दृष्टिकोण के साथ टोकन को प्रकट किया जा सकता है: ब्राउज़र इतिहास में, लॉग फाइलें, रेफरल हेडर।

टोकन के आधार पर एन्क्रिप्शन

यह दृष्टिकोण स्टेटलेस है, क्योंकि यह टोकन को मान्य करने के लिए एन्क्रिप्शन / डिक्रिप्शन का उपयोग करता है, और इसलिए इसे सर्वर पर टोकन के भंडारण की आवश्यकता नहीं होती है।

सर्वर एक सत्र पहचानकर्ता और टाइमस्टैम्प (एक फिर से खेलना हमले को रोकने के लिए) से मिलकर एक टोकन उत्पन्न करता है। एन्क्रिप्शन के लिए, GSM / GSM-SIV ब्लॉक एन्क्रिप्शन मोड में AES256 एन्क्रिप्शन एल्गोरिथ्म का उपयोग करने की सिफारिश की गई है। ईसीबी मोड का उपयोग करना दृढ़ता से हतोत्साहित किया जाता है। सर्वर द्वारा एन्क्रिप्ट किया गया टोकन क्लाइंट को उसी तरह से लौटाया जाता है, जैसे छिपे हुए फॉर्म फील्ड में या रिस्पांस हेडर / पैरामीटर में "सिंक्रोनाइजर टोकन" के मामले में। टोकन प्राप्त होने पर, सर्वर को इसे डिक्रिप्ट करना चाहिए, फिर सत्र पहचानकर्ता को सत्यापित करें, और वर्तमान समय के साथ टाइमस्टैम्प की भी जांच करें और सुनिश्चित करें कि यह सेट टोकन जीवनकाल से अधिक नहीं है।
यदि सत्र पहचानकर्ता का सत्यापन सफल है, लेकिन टाइममैप नहीं है, तो अनुरोध को वैध माना जा सकता है। अन्य सभी मामलों में, अनुरोध को अस्वीकार करने और इसे पंजीकृत करने के लिए सिफारिश की जाती है ताकि आगे इस तरह के अनुरोधों का जवाब दिया जा सके।

HMAC आधारित टोकन

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

टोकन स्वचालन

CSRF हमलों का मुकाबला करने में मुख्य समस्या यह है कि डेवलपर्स अक्सर टोकन के साथ काम करने के लिए कार्यक्षमता जोड़ना भूल जाते हैं। ऐसी समस्याओं से बचने के लिए, यह इस प्रक्रिया को स्वचालित करने के लायक है:

• एक आवरण लिखें जो फॉर्म टैग के माध्यम से या ajax का उपयोग करते समय स्वचालित रूप से एक अनुरोध जोड़ता है। उदाहरण के लिए, स्प्रिंग सिक्योरिटी हर बार समान रूप लेती है <form: form> टैग का उपयोग किया जाता है।

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

• पेज को रेंडर करते समय अपने आप एक टोकन जोड़ें। यह दृष्टिकोण CSRF गार्ड द्वारा उपयोग किया जाता है: टोकन सभी href और src विशेषताओं, छिपे हुए फ़ील्ड और सभी रूपों में जोड़े जाते हैं

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

CSRF लॉगिन करें

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

Samesite कुकी

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

एक विशेषता सेट करना बहुत आसान है:

 Set-Cookie: JSESSIONID=xxxxx; SameSite=Strict Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax

लेखन के समय, ब्राउज़र द्वारा विशेषता के लिए समर्थन इस तरह दिखता है:

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

हेडिंग चेक कर रहे हैं

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

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

सभी वर्णित विधियां केवल तभी काम करती हैं जब मूल और संदर्भित हेडर मौजूद होते हैं। लेकिन ऐसे मामले हैं जब ये हेडर गायब हैं। यहां कुछ मामले दिए गए हैं जहां ये हेडर अनुरोध में शामिल नहीं हैं:
• IE 11 में विश्वसनीय साइटों के लिए ओरिजिन हेडर शामिल नहीं है। यह केवल रेफ़र हैडर पर निर्भर रहना है।
• रीडायरेक्ट के मामले में, उत्पत्ति अनुरोध में शामिल नहीं है, क्योंकि यह माना जाता है कि इसमें गोपनीय जानकारी हो सकती है जिसे किसी अन्य स्रोत पर नहीं भेजा जाना चाहिए
• ओरिजिन हेडर सभी क्रॉस-साइट अनुरोधों के लिए सक्षम है, लेकिन अधिकांश ब्राउज़र इसे केवल पोस्ट / DELETE / PUT अनुरोधों के लिए जोड़ते हैं

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

डबल कुकी जमा करें

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

सुरक्षा क्रिब: सीएसआरएफ

More articles: