XSS और CSRF के बीच मौलिक अंतर और आधुनिक सुरक्षा उपाय

परिचय

आधुनिक वेब एप्लिकेशनों में, सुरक्षा केवल एक अतिरिक्त सुविधा नहीं है, बल्कि सिस्टम की नींव बनाने वाले सबसे महत्वपूर्ण तत्वों में से एक है। इनमें, XSS (Cross-Site Scripting) और CSRF (Cross-Site Request Forgery) पुरानी होने के बावजूद गंभीर भेद्यताएं हैं जो आज भी कई वेब एप्लिकेशनों में पाई जाती हैं। अक्सर इन्हें मिला दिया जाता है, लेकिन इनके हमले का तंत्र और उनके खिलाफ बचाव के उपाय मौलिक रूप से भिन्न होते हैं।

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

1. XSS (Cross-Site Scripting) की गहराई

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

XSS के 3 प्रमुख प्रकार

XSS का वर्गीकरण इस आधार पर किया जा सकता है कि डेटा कैसे संग्रहीत या परावर्तित होता है और उसकी असुरक्षित व्याख्या कहाँ होती है। ये श्रेणियाँ परस्पर अनन्य नहीं हैं: संग्रहीत या परावर्तित डेटा भी क्लाइंट पर असुरक्षित ढंग से संसाधित हो सकता है।

1. Stored XSS (संचित XSS)

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

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

2. Reflected XSS (परावर्तित XSS)

Reflected XSS तब होता है जब दुर्भावनापूर्ण स्क्रिप्ट सर्वर पर सहेजे बिना रिक्वेस्ट के हिस्से (जैसे URL पैरामीटर या फॉर्म डेटा) के रूप में भेजी जाती है, और सर्वर की प्रतिक्रिया में सीधे “परावर्तित” होकर शामिल होती है।

सामान्य घटना स्थल: खोज परिणाम पेज, त्रुटि संदेश का प्रदर्शन, चरणों के बीच डेटा पास करना आदि।
हमले की तकनीक: हमलावर उपयोगकर्ताओं को दुर्भावनापूर्ण पैरामीटर वाले URL पर क्लिक करवाकर (फिशिंग ईमेल या SNS का उपयोग करके) हमला करता है।

3. DOM-based XSS

DOM-आधारित XSS तब होता है जब क्लाइंट का JavaScript अविश्वसनीय डेटा को किसी असुरक्षित sink में संसाधित करता है। डेटा सर्वर से भी होकर आ सकता है; निर्णायक बात यह है कि असुरक्षित प्रसंस्करण क्लाइंट पर होता है।

तंत्र: यह तब होता है जब एप्लिकेशन का JavaScript हमलावर द्वारा नियंत्रित स्रोतों जैसे window.location या document.referrer से डेटा पढ़ता है, और इसे सीधे खतरनाक सिंक (निष्पादन बिंदु) जैसे innerHTML या eval() को पास कर देता है।
खतरा: यह अक्सर सर्वर लॉग में नहीं रहता है, जिससे WAF (Web Application Firewall) आदि द्वारा इसका पता लगाना मुश्किल हो सकता है।

XSS द्वारा नुकसान और संदर्भ में स्क्रिप्ट निष्पादन की तरकीबें

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

सत्र अपहरण (Session Hijacking): यदि प्रमाणीकरण Cookie में HttpOnly नहीं है, तो हमलावर document.cookie से सत्र ID चुरा सकता है। HttpOnly होने पर भी XSS उपयोगकर्ता की ओर से प्रमाणित अनुरोध भेज सकता है।
अनधिकृत कार्यों का निष्पादन: उपयोगकर्ता के अधिकार के साथ, एप्लिकेशन के भीतर कोई भी मनमाना कार्य (पासवर्ड बदलना, पैसे भेजना, संदेश भेजना आदि) बैकग्राउंड में निष्पादित किया जाता है।
फिशिंग (Phishing): DOM पर एक नकली लॉगिन फॉर्म बनाकर उपयोगकर्ता की प्रमाणीकरण जानकारी सीधे चुरा ली जाती है।
मैलवेयर वितरण: उपयोगकर्ता के ब्राउज़र को एक्सप्लॉइट किट पर रीडायरेक्ट करके पीसी को मैलवेयर से संक्रमित किया जाता है।

XSS के खिलाफ आधुनिक सुरक्षा उपाय

XSS को रोकने के लिए, बहु-स्तरीय रक्षा (Defense in Depth) दृष्टिकोण आवश्यक है।

1. संदर्भ-विशिष्ट एस्केप प्रोसेसिंग (Output Encoding)

सबसे बुनियादी और महत्वपूर्ण उपाय उपयोगकर्ताओं के इनपुट को वेब पेज पर आउटपुट करते समय हानिरहित स्ट्रिंग्स में बदलने की एस्केप (एनकोडिंग) प्रक्रिया है। महत्वपूर्ण बात यह है कि डेटा आउटपुट होने वाले संदर्भ (HTML बॉडी, HTML विशेषता, JavaScript के भीतर, CSS के भीतर, URL के भीतर आदि) के आधार पर उचित एस्केप विधि का चयन किया जाए। आधुनिक वेब फ्रेमवर्क (React, Vue, Angular आदि) डिफ़ॉल्ट रूप से HTML को एस्केप करते हैं, लेकिन फिर भी सावधानी बरतने की आवश्यकता है।

2. CSP (Content Security Policy) का परिचय

CSP, XSS के खिलाफ एक बहुत ही शक्तिशाली रक्षा तंत्र है, जो उन संसाधनों की एक श्वेतसूची को HTTP हेडर में परिभाषित करता है जिन्हें ब्राउज़र लोड और निष्पादित करने की अनुमति देता है।

1
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com;

इससे, भले ही कोई हमलावर इनलाइन स्क्रिप्ट <script>alert(1)</script> को इंजेक्ट करने में सफल हो जाए, CSP द्वारा इसका निष्पादन रोक दिया जाएगा।

सत्र ID आदि को संग्रहीत करने वाली Cookie में HttpOnly विशेषता जोड़कर, JavaScript (जैसे document.cookie) से उस Cookie तक पहुंच को रोका जा सकता है। यह XSS की घटना को स्वयं नहीं रोकता है, लेकिन यह एक महत्वपूर्ण शमन उपाय है जो XSS के कारण सत्र अपहरण के जोखिम को काफी कम कर देता है।

2. CSRF (Cross-Site Request Forgery) का सार

CSRF एक हमला है जहां एक हमलावर उपयोगकर्ता को एक ट्रैप साइट पर ले जाता है और उसे किसी अन्य वेबसाइट पर अनजाने में एक रिक्वेस्ट भेजने के लिए मजबूर करता है जहां उपयोगकर्ता पहले से ही प्रमाणित (लॉग इन) है।

जहां XSS “ब्राउज़र के भीतर दुर्भावनापूर्ण स्क्रिप्ट को निष्पादित करता है”, वहीं CSRF “ब्राउज़र के मानक व्यवहार (Cookie का स्वचालित ट्रांसमिशन) का फायदा उठाकर दुर्भावनापूर्ण रिक्वेस्ट भेजता है”। यह एक महत्वपूर्ण अंतर है।

Cookie भेजने की शर्तें पूरी होने पर ब्राउज़र उसे स्वतः जोड़ता है। इसमें दूसरे साइट के चित्र या फॉर्म से शुरू हुए कुछ अनुरोध भी शामिल हो सकते हैं। लेकिन SameSite, Secure, Domain, Path और ब्राउज़र की Cookie संबंधी पाबंदियाँ उसका भेजा जाना रोक सकती हैं।

हमले का परिदृश्य:

यह शैक्षिक उदाहरण एक असुरक्षित एप्लिकेशन मानता है: प्रमाणीकरण Cookie SameSite=None; Secure के साथ क्रॉस-साइट भेजी जा सकती है, और CSRF टोकन या Origin की जाँच नहीं होती। bank.example और attacker.invalid अलग-अलग साइटों के आरक्षित उदाहरण डोमेन हैं।

उपयोगकर्ता बैंक साइट (bank.example) में लॉग इन करता है और एक सत्र Cookie प्राप्त करता है।
उपयोगकर्ता एक अलग टैब में हमलावर की ट्रैप साइट (attacker.invalid) देखता है।

ट्रैप साइट में निम्नलिखित जैसा एक छिपा हुआ फॉर्म और एक स्वचालित ट्रांसमिशन स्क्रिप्ट है:

1
2
3
4
5
<form action="https://bank.example/transfer" method="POST" id="csrf-form">
    <input type="hidden" name="toAccount" value="ATTACKER_ACCOUNT">
    <input type="hidden" name="amount" value="1000000">
</form>
<script>document.getElementById('csrf-form').submit();</script>

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

CSRF के खिलाफ सुरक्षा उपायों का ऐतिहासिक विकास और नवीनतम प्रथाएं

CSRF को रोकने के लिए, यह सत्यापित करना आवश्यक है कि क्या रिक्वेस्ट “किसी इच्छित वैध पेज से भेजी गई थी”।

1. CSRF टोकन (Anti-CSRF Tokens): पारंपरिक और विश्वसनीय बचाव

CSRF टोकन (Synchronizer Token Pattern) सबसे पुराना और सबसे व्यापक रूप से इस्तेमाल किया जाने वाला विश्वसनीय बचाव है।

सर्वर प्रत्येक सत्र के लिए एक अप्रत्याशित यादृच्छिक टोकन उत्पन्न करता है और इसे सर्वर साइड (जैसे सत्र) पर सहेजता है।
यह टोकन क्लाइंट को भेजे गए HTML फॉर्म के भीतर एक छिपे हुए (hidden) क्षेत्र के रूप में एम्बेड किया जाता है।
फॉर्म सबमिट करते समय, सर्वर भेजे गए टोकन की तुलना सर्वर साइड पर सहेजे गए टोकन से करता है और दोनों के मेल खाने पर ही रिक्वेस्ट को प्रोसेस करता है। भले ही हमलावर ट्रैप साइट से रिक्वेस्ट भेज सकें, लेकिन वे लक्ष्य साइट के पेज को पढ़कर सही टोकन प्राप्त नहीं कर सकते (Same-Origin Policy के कारण), इसलिए हमला विफल हो जाता है।

यह अक्सर उन API में उपयोग की जाने वाली तकनीक है जिनकी सर्वर साइड पर स्थिति (सत्र) नहीं होती है।

सर्वर एक यादृच्छिक टोकन उत्पन्न करता है और इसे Cookie के रूप में क्लाइंट को भेजता है।
क्लाइंट का JavaScript उस Cookie के मान को पढ़ता है और उसे भेजते समय रिक्वेस्ट हेडर (उदाहरण के लिए: X-CSRF-Token) में सेट करता है।
सर्वर जाँचता है कि Cookie और अनुरोध के हेडर में टोकन के मान समान हैं या नहीं। ऊपर के चरण केवल समानता की साधारण जाँच बताते हैं। यदि हमलावर Cookie इंजेक्ट कर सकता है, तो केवल इस जाँच पर निर्भर रहना उचित नहीं है। फ्रेमवर्क की अंतर्निहित सुरक्षा को प्राथमिकता दें। Double Submit का उपयोग करने पर सर्वर के गुप्त कुंजी से HMAC-प्रमाणित और वर्तमान प्रमाणित सत्र से बँधे Signed Double Submit टोकन को सत्यापित करें। कस्टम हेडर वाले API को अविश्वसनीय origin के लिए क्रेडेंशियल सहित CORS पहुँच भी नहीं देनी चाहिए।

SameSite विशेषता क्रॉस-साइट अनुरोधों में Cookie भेजने को नियंत्रित करती है और सुरक्षा की एक परत है। सामान्य एप्लिकेशनों में इसे CSRF टोकन या Origin जाँच के साथ उपयोग करें, उनके विकल्प के रूप में नहीं।

SameSite=Strict: किसी भी क्रॉस-साइट रिक्वेस्ट में Cookie नहीं भेजी जाएगी, जिसमें लिंक क्लिक जैसे शीर्ष-स्तरीय नेविगेशन शामिल हैं। यह सबसे सुरक्षित है, लेकिन इसका UX पर प्रभाव पड़ सकता है, जैसे कि किसी अन्य साइट के लिंक से लॉगिन स्थिति को बनाए नहीं रखना।
SameSite=Lax: छवियों को लोड करने या POST रिक्वेस्ट जैसे क्रॉस-साइट रिक्वेस्ट में Cookie नहीं भेजी जाती है, लेकिन इसे लिंक क्लिक (GET रिक्वेस्ट) के माध्यम से शीर्ष-स्तरीय नेविगेशन के लिए भेजा जाता है। यह वर्तमान में कई ब्राउज़रों का डिफ़ॉल्ट व्यवहार है। यह दुर्भावनापूर्ण POST फॉर्म सबमिशन के कारण होने वाले अधिकांश CSRF को रोक सकता है।
SameSite=None: क्रॉस-साइट भेजने पर SameSite की पाबंदी हटाता है और Secure आवश्यक है। Cookie भेजने की अन्य शर्तें और ब्राउज़र की पाबंदियाँ लागू रहती हैं।

SameSite साइटों में भेद करता है, origin में नहीं: एक ही पंजीकरण-योग्य डोमेन के सहोदर सबडोमेन एक ही साइट माने जा सकते हैं। Lax उस endpoint को भी सुरक्षित नहीं करता जो GET से स्थिति बदलता है। स्थिति बदलने के लिए उचित HTTP विधियाँ और सर्वर पर CSRF जाँच उपयोग करें। ब्राउज़र के डिफ़ॉल्ट Lax व्यवहार में अपवाद हो सकते हैं, इसलिए आवश्यक Cookie विशेषताएँ स्पष्ट रूप से सेट करें।

XSS और CSRF के बीच संबंध और निष्कर्ष

नीचे दिया गया आरेख हमलों के प्रवाह में अंतर को दर्शाता है।

  graph TD
    subgraph XSS Attack
        A["हमलावर"] -- "दुर्भावनापूर्ण स्क्रिप्ट इंजेक्शन" --> B["वेब सर्वर"]
        B -- "स्क्रिप्ट वाला पेज" --> C["शिकार का ब्राउज़र"]
        C -- "सत्र ID की चोरी (HttpOnly के बिना)" --> A
    end

    subgraph CSRF Attack
        D["शिकार"] -- "लॉग इन" --> E["वेब सर्वर"]
        D -- "ब्राउज़िंग" --> F["हमलावर की ट्रैप साइट"]
        F -- "मजबूर रिक्वेस्ट (Cookie के साथ)" --> E
    end

हालाँकि XSS और CSRF अलग-अलग भेद्यताएं हैं, यदि XSS मौजूद है, तो अधिकांश CSRF सुरक्षा उपाय अप्रभावी हो जाते हैं। ऐसा इसलिए है क्योंकि XSS द्वारा निष्पादित स्क्रिप्ट एक वैध पेज के भीतर चल रही है, जिससे CSRF टोकन को पढ़ना और उसी मूल (origin) से रिक्वेस्ट भेजना संभव हो जाता है।

इसलिए, वेब एप्लिकेशन की सुरक्षा सुनिश्चित करने के लिए, एक मजबूत नींव बनाना आवश्यक है: पहले XSS को पूरी तरह से ब्लॉक करना (उचित एस्केपिंग और CSP), और फिर CSRF काउंटरमेजर (SameSite Cookie और CSRF टोकन) को लागू करना।

डेवलपर्स के लिए यह महत्वपूर्ण है कि वे फ्रेमवर्क द्वारा प्रदान की जाने वाली सुरक्षा सुविधाओं पर अत्यधिक भरोसा न करें, बल्कि इन भेद्यताओं के मौलिक तंत्र को समझें और उचित स्तरों पर रक्षा डिजाइन करें।