सोचिए कि कोई विज़िटर अपने बैंक अकाउंट में लॉग इन है और कोई उसे एक लिंक पर क्लिक करने के लिए बहका देता है। वह लिंक एक छिपे हुए फ़ॉर्म तक ले जाता है, जो विज़िटर को पता चले बिना बैंक को पैसे ट्रांसफ़र करने की रिक्वेस्ट भेज देता है। बैंक को लगता है कि यह एक लॉग इन यूज़र की सही रिक्वेस्ट है और वह उसे प्रोसेस कर देता है। हमलावर ने पीड़ित का पासवर्ड जाने बिना ही उसके अकाउंट से पैसे हिला दिए।
यही है CSRF (Cross-Site Request Forgery): एक ऐसा हमला जिसमें हमलावर किसी पीड़ित को बहकाकर उससे अनजाने में किसी दूसरी वेबसाइट पर फ़ॉर्म या रिक्वेस्ट सबमिट करवा देता है, जहाँ पीड़ित पहले से लॉग इन है।
आप क्या सीखेंगे: CSRF अटैक क्या होते हैं और कैसे काम करते हैं, दूसरे सुरक्षा उपाय होने पर भी ये इतने खतरनाक क्यों हैं, CSRF टोकन इन्हें कैसे रोकते हैं, और अपने फ़ॉर्म पर प्रोटेक्शन कैसे लगाएं।
CSRF क्या है?
CSRF (उच्चारण "सी-सर्फ़") का मतलब है Cross-Site Request Forgery। यह ऐसा हमला है जिसमें हमलावर इस बात का फ़ायदा उठाता है कि अगर आप किसी वेबसाइट पर लॉग इन हैं, तो आपका ब्राउज़र उस साइट पर भेजी गई हर रिक्वेस्ट के साथ आपका सेशन अपने आप भेज देता है, भले ही रिक्वेस्ट किसी दूसरी वेबसाइट से आई हो।
यह हमला इस तरह काम करता है कि लॉग इन विज़िटर से अनजाने में उस वेबसाइट पर फ़ॉर्म सबमिट करवा दिया जाता है जहाँ उसका अकाउंट है। हमलावर पीड़ित का पासवर्ड नहीं देख सकता। उसे ज़रूरत भी नहीं है। उसे बस इतना चाहिए कि पीड़ित पहले से लॉग इन हो, और फिर उसे ऐसी रिक्वेस्ट (जैसे छिपा फ़ॉर्म सबमिट करना) करने के लिए बहकाया जाए जो हमलावर का मनचाहा काम कर दे।
CSRF दूसरे हमलों से अलग है, क्योंकि इसमें क्रेडेंशियल चुराने या एन्क्रिप्शन तोड़ने की ज़रूरत नहीं पड़ती। यह वेबसाइट पर पीड़ित के भरोसे का फ़ायदा उठाता है। पीड़ित पहले से ऑथेंटिकेटेड है, इसलिए वेबसाइट उन रिक्वेस्ट पर भरोसा कर लेती है जो उसकी ओर से आती दिखती हैं।
CSRF अटैक कैसे काम करते हैं
CSRF अटैक तीन स्टेप में होता है।
स्टेप 1: पीड़ित आपकी साइट पर लॉग इन है
कोई आपकी वेबसाइट पर आता है और अपने अकाउंट में लॉग इन करता है। अब उसके ब्राउज़र में एक चालू सेशन कुकी होती है जो साबित करती है कि वह ऑथेंटिकेटेड है। जब तक वह साइट इस्तेमाल करता रहता है, यह सेशन चालू रहता है।
स्टेप 2: हमलावर उसे किसी नुकसानदेह पेज पर जाने के लिए बहकाता है
आपकी साइट पर लॉग इन रहते हुए ही पीड़ित एक ऐसे पेज पर जाता है जो हमलावर के कंट्रोल में है (शायद सोशल मीडिया का कोई लिंक, गुमराह करने वाला विज्ञापन, या असली दिखने वाली कोई वेबसाइट)। उस पेज पर छिपा हुआ कोड होता है जो आपकी साइट पर एक फ़ॉर्म सबमिट कर देता है।
स्टेप 3: फ़ॉर्म पीड़ित के सेशन से अपने आप सबमिट हो जाता है
छिपा फ़ॉर्म आपकी वेबसाइट पर सबमिट होता है। क्योंकि पीड़ित पहले से लॉग इन है, उसका ब्राउज़र रिक्वेस्ट के साथ उसकी सेशन कुकी अपने आप जोड़ देता है। आपके फ़ॉर्म को यह एक ऑथेंटिकेटेड यूज़र की जायज़ रिक्वेस्ट लगती है। फ़ॉर्म उसे ऐसे प्रोसेस कर देता है जैसे पीड़ित ने जानबूझकर सबमिट किया हो।
अब हमलावर ने पीड़ित के अकाउंट से आपकी साइट पर कुछ कर दिया, और पीड़ित को पता तक नहीं चला। हो सकता है उसने पासवर्ड बदल दिया हो, पैसे ट्रांसफ़र कर दिए हों, प्रोफ़ाइल अपडेट कर दी हो, या कोई डेटा सबमिट कर दिया हो।
दूसरे सुरक्षा उपाय होने पर भी यह क्यों काम करता है
CSRF अटैक कई आम सुरक्षा फ़ीचर को बायपास कर देते हैं:
HTTPS CSRF को नहीं रोकता। डेटा रास्ते में एन्क्रिप्टेड रहता है, लेकिन हमलावर को उसे बीच में पकड़ने की ज़रूरत ही नहीं है। वह रिक्वेस्ट सीधे पीड़ित के ब्राउज़र से भेजता है, जिस पर पीड़ित का ब्राउज़र पहले से भरोसा करता है।
पासवर्ड प्रोटेक्शन CSRF को नहीं रोकती। हमलावर को पीड़ित के पासवर्ड की कभी ज़रूरत नहीं पड़ती। वह बस इस बात का फ़ायदा उठाता है कि पीड़ित पहले से लॉग इन है।
मज़बूत लॉग इन सिस्टम CSRF को नहीं रोकता। ऑथेंटिकेशन बिल्कुल सही हो, तब भी अगर पीड़ित लॉग इन है तो हमला चल जाता है।
इसीलिए CSRF प्रोटेक्शन अपनी अलग परत है। इसे दूसरे सुरक्षा उपाय नहीं रोकते। आपको फ़ॉर्म को खास तौर पर CSRF अटैक का सामना करने लायक बनाना पड़ता है।
CSRF टोकन: ये हमले को कैसे रोकते हैं
इसका हल है CSRF टोकन। यह एक अनोखी, अनुमान न लगाई जा सकने वाली स्ट्रिंग है जो आपका सर्वर हर फ़ॉर्म के लिए बनाता है। यह ऐसे काम करता है:
आपका सर्वर हर विज़िटर के लिए एक अनोखा टोकन बनाता है
जब कोई फ़ॉर्म वाला पेज खोलता है, तो आपका सर्वर एक रैंडम टोकन बनाता है और उसे उस यूज़र के सेशन से जोड़ देता है। यह टोकन हर बार अलग होता है और उस यूज़र के लिए अनोखा होता है।
टोकन फ़ॉर्म में जोड़ा जाता है
टोकन HTML फ़ॉर्म में एक छिपे फ़ील्ड के रूप में रहता है। जब विज़िटर फ़ॉर्म सबमिट करता है, तो टोकन भी साथ जाता है।
सबमिशन प्रोसेस करने से पहले आपका सर्वर टोकन जाँचता है
फ़ॉर्म सबमिट होने पर आपका सर्वर देखता है कि सबमिशन में आया टोकन उस टोकन से मेल खाता है या नहीं जो उसने इस यूज़र के सेशन के लिए बनाया था। अगर मेल खाता है, तो फ़ॉर्म प्रोसेस हो जाता है। अगर नहीं (या कोई टोकन ही नहीं है), तो फ़ॉर्म रिजेक्ट कर दिया जाता है।
हमलावर का छिपा फ़ॉर्म वैध टोकन नहीं जोड़ सकता, क्योंकि टोकन अनुमान से परे होते हैं और हर सेशन के लिए अनोखे होते हैं। दूसरे डोमेन पर बैठा हमलावर टोकन देख या अंदाज़ा नहीं लगा सकता। इसलिए उसका हमला नाकाम हो जाता है। छिपा फ़ॉर्म सबमिट तो होता है, लेकिन आपका सर्वर उसे रिजेक्ट कर देता है क्योंकि टोकन मेल नहीं खाता।
असल में CSRF टोकन कैसा दिखता है
HTML में CSRF से सुरक्षित फ़ॉर्म कुछ ऐसा दिखता है:
<form method="POST" action="/submit-form"> <input type="hidden" name="csrf_token" value="a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"> <input type="email" name="email" placeholder="Your email"> <button type="submit">Submit</button> </form>`csrf_token` फ़ील्ड छिपा हुआ है। विज़िटर उसे नहीं देखता, लेकिन वह फ़ॉर्म के डेटा के साथ सबमिट हो जाता है। आपका सर्वर ईमेल या किसी और डेटा को प्रोसेस करने से पहले उसे जाँचता है।
अलग-अलग तरह के फ़ॉर्म के लिए CSRF प्रोटेक्शन
पारंपरिक HTML फ़ॉर्म
स्टैंडर्ड HTML फ़ॉर्म (जो आपके सर्वर पर डेटा POST करते हैं) को CSRF टोकन चाहिए। इनमें कॉन्टैक्ट फ़ॉर्म, लॉग इन फ़ॉर्म, पासवर्ड रीसेट फ़ॉर्म और हर वह फ़ॉर्म शामिल है जो आपके सर्वर पर डेटा बदलता है।
AJAX और JavaScript फ़ॉर्म
JavaScript से API endpoint पर सबमिट होने वाले फ़ॉर्म को भी CSRF प्रोटेक्शन चाहिए। टोकन फ़ॉर्म में ही जोड़ा जा सकता है, कुकी में रखा जा सकता है, या रिक्वेस्ट भेजने से पहले मेटा टैग से लिया जा सकता है।
स्टेटलेस API रिक्वेस्ट
अगर आपकी API टोकन-आधारित ऑथेंटिकेशन (जैसे JWT) इस्तेमाल करती है, तो CSRF प्रोटेक्शन अलग तरह से काम करती है। ब्राउज़र JWT टोकन को उस तरह अपने आप नहीं जोड़ सकता जैसे वह सेशन कुकी जोड़ता है, इसलिए पारंपरिक CSRF का खतरा कम होता है। फिर भी बेहतर तरीका यही है कि अतिरिक्त सुरक्षा के लिए एक और CSRF टोकन जोड़ा जाए।
CSRF टोकन के साथ काम करने वाली दूसरी सुरक्षाएँ
CSRF टोकन मुख्य बचाव हैं, लेकिन वे दूसरी सुरक्षा आदतों के साथ सबसे अच्छा काम करते हैं।
SameSite कुकी
सेशन कुकी सेट करते समय आप `SameSite` एट्रिब्यूट जोड़ सकते हैं, जो ब्राउज़र को बताता है कि दूसरे डोमेन से आई रिक्वेस्ट में कुकी न भेजे। इससे हमलावर का छिपा फ़ॉर्म पीड़ित का सेशन इस्तेमाल ही नहीं कर पाता।
Referer हेडर की जाँच
आपका सर्वर Referer हेडर देखकर पता कर सकता है कि रिक्वेस्ट कहाँ से आई। अगर फ़ॉर्म सबमिशन आपके डोमेन से आने का दावा करता है लेकिन Referer में कोई दूसरा डोमेन दिखता है, तो वह शायद हमला है। (हालाँकि Referer हेडर नकली भी बनाए जा सकते हैं, इसलिए यह पूरा बचाव नहीं है।)
डबल-सबमिट कुकी पैटर्न
इस तरीके में CSRF टोकन कुकी और फ़ॉर्म फ़ील्ड, दोनों में रखा जाता है। आपका सर्वर प्रोसेस करने से पहले जाँचता है कि दोनों मेल खाते हैं। यह पारंपरिक टोकन से कम इस्तेमाल होता है, लेकिन स्टेटलेस एप्लिकेशन के लिए अच्छा काम करता है।
CSRF प्रोटेक्शन कैसे लागू करें
लागू करने का तरीका आपकी टेक्नोलॉजी स्टैक पर निर्भर करता है, लेकिन पैटर्न एक ही है:
- हर सेशन के लिए अनोखा टोकन बनाएं। जब यूज़र सेशन शुरू करता है या फ़ॉर्म वाला पेज खोलता है, तो आपका बैकएंड नया टोकन बनाता है।
- टोकन को सर्वर साइड पर रखें। उसे उस यूज़र के सेशन से जोड़कर सेव करें।
- टोकन को फ़ॉर्म में जोड़ें। उसे HTML में छिपे फ़ील्ड के रूप में या मेटा टैग के रूप में जोड़ें जिसे JavaScript पढ़ सके।
- सबमिशन पर वैलिडेट करें। कोई भी फ़ॉर्म डेटा प्रोसेस करने से पहले जाँचें कि सबमिट किया गया टोकन उस सेशन के सेव किए टोकन से मेल खाता है।
- संवेदनशील एक्शन के बाद दोबारा बनाएं। जब यूज़र पासवर्ड बदलता है या कोई ज़रूरी काम करता है, तो नया टोकन बनाएं।
ज़्यादातर आधुनिक फ़्रेमवर्क (Django, Rails, Laravel, ASP.NET) CSRF टोकन बनाना और वैलिडेट करना अपने आप संभाल लेते हैं। अगर आप कोई फ़्रेमवर्क इस्तेमाल कर रहे हैं, तो CSRF प्रोटेक्शन आम तौर पर डिफ़ॉल्ट रूप से चालू होती है। बस ध्यान रखें कि उसे गलती से बंद न कर दें।
आम गलतियाँ जो फ़ॉर्म को असुरक्षित छोड़ देती हैं
सुविधा के लिए CSRF प्रोटेक्शन बंद करना। कुछ डेवलपर API टेस्टिंग आसान करने या अपना कोड सरल रखने के लिए CSRF जाँच बंद कर देते हैं। ऐसा न करें। इससे असली कमज़ोरी बन जाती है।
सभी यूज़र के लिए एक ही स्टैटिक टोकन इस्तेमाल करना। टोकन हर यूज़र के सेशन के लिए अनोखा होना चाहिए। जो टोकन सबके लिए एक ही हो (या सभी दिनों में सभी यूज़र के लिए एक ही हो), वह CSRF से बचाव नहीं करता।
टोकन दोबारा न बनाना। अगर आप हफ़्तों तक एक ही टोकन इस्तेमाल करते हैं, तो हमलावर के पास उसका फ़ायदा उठाने के लिए ज़्यादा समय होता है। टोकन नियमित रूप से और संवेदनशील कामों के बाद हमेशा दोबारा बनाएं।
सिर्फ़ SameSite कुकी पर निर्भर रहना। SameSite मददगार है लेकिन काफ़ी नहीं है। CSRF टोकन को मुख्य बचाव रखें और SameSite को बैकअप।
कुछ फ़ॉर्म पर टोकन भूल जाना। अगर आप कुछ फ़ॉर्म को टोकन से सुरक्षित करते हैं और बाकी को नहीं, तो हमलावर असुरक्षित फ़ॉर्म इस्तेमाल करेंगे। डेटा बदलने वाले हर फ़ॉर्म को प्रोटेक्शन चाहिए।
CSRF प्रोटेक्शन और WEMASY
WEMASY में आप वेबसाइट बिल्डर से अपनी वेबसाइट पर फ़ॉर्म जोड़ सकते हैं। फ़ॉर्म की सुरक्षा के लिए ऊपर बताई बातें अपने सेटअप में जाँचें, ख़ासकर अगर आप अपना कस्टम कोड जोड़ते हैं।
WEMASY के प्लान और कीमतें प्राइसिंग पेज पर देखें।