कल्पना कीजिए कि आपके पास एक वेबसाइट थी, जो एक सरलीकृत ट्विटर की तरह थी, जिसे एक.com पर होस्ट किया गया था। उपयोगकर्ताओं में हस्ताक्षर किए गए कुछ पाठ (एक ट्वीट) को एक फॉर्म में दर्ज कर सकते हैं जो सर्वर पर एक पोस्ट अनुरोध के रूप में भेजा जा रहा है और सबमिट बटन पर हिट होने पर प्रकाशित होता है। सर्वर पर उपयोगकर्ता को उनके अद्वितीय सत्र आईडी वाले कुकी द्वारा पहचाना जाता है, इसलिए आपका सर्वर जानता है कि ट्वीट किसने पोस्ट किया है।
फार्म उतना ही सरल हो सकता है:
<form action="http://a.com/tweet" method="POST">
<input type="text" name="tweet">
<input type="submit">
</form>
अब कल्पना कीजिए, एक बुरा आदमी अपनी दुर्भावनापूर्ण वेबसाइट पर इस फॉर्म को कॉपी और पेस्ट करता है, आइए b.com कहते हैं। पर्चा अभी भी काम करेगा। जब तक किसी उपयोगकर्ता को आपके ट्विटर पर साइन इन किया जाता है (यानी उन्हें a.com के लिए एक वैध सत्र कुकी मिल जाती है), तब तक POST अनुरोध भेजा
http://a.com/tweetऔर संसाधित किया जाएगा जब उपयोगकर्ता सबमिट बटन पर क्लिक करता है।
अब तक यह एक बड़ा मुद्दा नहीं है जब तक कि उपयोगकर्ता को इस बारे में अवगत कराया जाता है कि फॉर्म वास्तव में क्या करता है, लेकिन क्या होगा यदि हमारा बुरा आदमी इस तरह से फॉर्म को ट्विस्ट करता है:
<form action="https://example.com/tweet" method="POST">
<input type="hidden" name="tweet" value="Buy great products at http://b.com/#iambad">
<input type="submit" value="Click to win!">
</form>
अब, यदि आपका कोई उपयोगकर्ता बुरे आदमी की वेबसाइट पर समाप्त होता है और "जीतने के लिए क्लिक करें" हिट करता है! बटन, प्रपत्र आपकी वेबसाइट पर प्रस्तुत किया जाता है, उपयोगकर्ता कुकी में सत्र आईडी द्वारा सही ढंग से पहचाना जाता है और छिपा हुआ ट्वीट प्रकाशित हो जाता है।
यदि हमारा बुरा आदमी और भी बुरा था, तो वह निर्दोष उपयोगकर्ता को यह फ़ॉर्म सबमिट कर देगा जैसे ही वे जावास्क्रिप्ट का उपयोग करके अपना वेब पेज खोलते हैं, शायद एक अदृश्य आइफ्रेम में पूरी तरह से छिपा हुआ हो। यह मूल रूप से क्रॉस-साइट अनुरोध जालसाजी है।
एक फॉर्म आसानी से हर जगह से हर जगह जमा किया जा सकता है। आम तौर पर यह एक सामान्य विशेषता है, लेकिन कई और मामले हैं जहां यह महत्वपूर्ण है कि केवल उस फॉर्म को डोमेन से सबमिट किया जाए जहां वह है।
यदि आपका वेब एप्लिकेशन POST और GET अनुरोधों (जैसे PHP में $ _POST के बजाय $ _REQUEST का उपयोग करके) के बीच अंतर नहीं करता है, तो हालात और भी बदतर हैं। ऐसा मत करो! <img src="http://a.com/tweet?tweet=This+is+really+bad">दुर्भावनापूर्ण वेबसाइट या यहां तक कि ईमेल में एम्बेड किए गए डेटा परिवर्तन अनुरोधों को जितना आसान हो सके प्रस्तुत किया जा सकता है ।
मैं यह कैसे सुनिश्चित कर सकता हूं कि कोई फॉर्म केवल मेरी अपनी वेबसाइट से सबमिट किया जा सकता है? यह वह जगह है जहाँ CSRF टोकन आता है। CSRF टोकन एक यादृच्छिक, कठोर-से-अनुमानित स्ट्रिंग है। आपके द्वारा सुरक्षित किए जाने वाले फ़ॉर्म वाले पृष्ठ पर, सर्वर एक यादृच्छिक स्ट्रिंग, CSRF टोकन उत्पन्न करेगा, इसे एक छिपे हुए फ़ील्ड के रूप में जोड़ें और इसे किसी तरह याद भी रखें, या तो इसे सत्र में संग्रहीत करके या कुकी सेट करके मान युक्त। अब फॉर्म इस तरह दिखेगा:
<form action="https://example.com/tweet" method="POST">
<input type="hidden" name="csrf-token" value="nc98P987bcpncYhoadjoiydc9ajDlcn">
<input type="text" name="tweet">
<input type="submit">
</form>
जब उपयोगकर्ता प्रपत्र सबमिट करता है, तो सर्वर को केवल सर्वर द्वारा याद किए गए CSRF टोकन के साथ पोस्ट किए गए फ़ील्ड csrf-token (नाम से कोई फर्क नहीं पड़ता) के मूल्य की तुलना करनी होती है। यदि दोनों स्ट्रिंग्स समान हैं, तो सर्वर प्रपत्र को संसाधित करना जारी रख सकता है। अन्यथा सर्वर को तुरंत फॉर्म को संसाधित करना बंद कर देना चाहिए और एक त्रुटि के साथ जवाब देना चाहिए।
यह काम क्यों करता है? ऊपर हमारे उदाहरण से खराब आदमी CSRF टोकन प्राप्त करने में असमर्थ होने के कई कारण हैं:
हमारे पेज से स्थैतिक स्रोत कोड को एक अलग वेबसाइट पर कॉपी करना बेकार होगा, क्योंकि प्रत्येक उपयोगकर्ता के साथ छिपे हुए फ़ील्ड का मूल्य बदल जाता है। वर्तमान उपयोगकर्ता के CSRF टोकन को जानने वाले बुरे व्यक्ति की वेबसाइट के बिना आपका सर्वर हमेशा POST अनुरोध को अस्वीकार करेगा।
क्योंकि बुरे आदमी का दुर्भावनापूर्ण पृष्ठ आपके उपयोगकर्ता के ब्राउज़र द्वारा किसी भिन्न डोमेन (a.com के बजाय b.com) से लोड किया गया है, बुरे व्यक्ति के पास जावास्क्रिप्ट कोड करने का कोई मौका नहीं है, जिससे सामग्री लोड होती है और इसलिए हमारे उपयोगकर्ता के वर्तमान CSRF टोकन से आपका वेबसाइट। ऐसा इसलिए है क्योंकि वेब ब्राउज़र डिफ़ॉल्ट रूप से क्रॉस-डोमेन AJAX अनुरोधों की अनुमति नहीं देते हैं।
खराब आदमी आपके सर्वर द्वारा कुकी सेट तक पहुंचने में असमर्थ है, क्योंकि डोमेन मेल नहीं खाते।
मुझे क्रॉस-साइट अनुरोध जालसाजी के खिलाफ कब रक्षा करनी चाहिए? यदि आप यह सुनिश्चित कर सकते हैं कि आप ऊपर वर्णित के रूप में GET, POST और अन्य अनुरोध विधियों को नहीं मिलाते हैं, तो डिफ़ॉल्ट रूप से सभी POST अनुरोधों की सुरक्षा के लिए एक अच्छी शुरुआत होगी।
आपको PUT और DELETE अनुरोधों की रक्षा करने की आवश्यकता नहीं है, क्योंकि जैसा कि ऊपर बताया गया है, उन तरीकों का उपयोग करके ब्राउज़र द्वारा एक मानक HTML फॉर्म जमा नहीं किया जा सकता है।
दूसरी ओर जावास्क्रिप्ट वास्तव में अन्य प्रकार के अनुरोध कर सकती है, जैसे jQuery के $ .ajax () फ़ंक्शन का उपयोग करना, लेकिन याद रखें, AJAX के अनुरोधों के लिए डोमेन से मेल खाना चाहिए (जब तक आप स्पष्ट रूप से अपने वेब सर्वर को अन्यथा कॉन्फ़िगर नहीं करते हैं) ।
इसका मतलब है, अक्सर आपको AJAX अनुरोधों में CSRF टोकन जोड़ने की आवश्यकता नहीं होती है, भले ही वे POST अनुरोध हों, लेकिन आपको यह सुनिश्चित करना होगा कि आप अपने वेब अनुप्रयोग में केवल CSRF चेक को बायपास करें यदि POST अनुरोध वास्तव में है AJAX का अनुरोध। आप एक्स-रिक्वेस्टेड-विथ हेडर की उपस्थिति की तलाश कर सकते हैं, जिसमें AJAX के अनुरोध आमतौर पर शामिल होते हैं। आप एक अन्य कस्टम हेडर भी सेट कर सकते हैं और सर्वर साइड पर इसकी उपस्थिति के लिए जाँच कर सकते हैं। यह सुरक्षित है, क्योंकि एक ब्राउज़र नियमित HTML फॉर्म सबमिशन (ऊपर देखें) में कस्टम हेडर नहीं जोड़ेगा, इसलिए श्री बैड गाइ के लिए इस व्यवहार को एक फॉर्म के साथ अनुकरण करने का कोई मौका नहीं है।
यदि आप AJAX अनुरोधों के बारे में संदेह में हैं, क्योंकि किसी कारण से आप X-Requested-With जैसे शीर्ष लेख के लिए जाँच नहीं कर सकते हैं, तो बस अपने CSRF उत्पन्न किए गए CSRF को अपने जावास्क्रिप्ट में पास करें और AJAX अनुरोध में टोकन जोड़ें। इसे करने के कई तरीके हैं; या तो इसे नियमित रूप से HTML फॉर्म की तरह पेलोड में जोड़ें, या AJAX अनुरोध में एक कस्टम हेडर जोड़ें। जब तक आपका सर्वर जानता है कि आने वाले अनुरोध में उसे कहां देखना है और वह इसे उस मूल मूल्य से तुलना करने में सक्षम है जिसे वह सत्र या कुकी से याद करता है, तो आप क्रमबद्ध हैं।