मोबाइल डेवलपमेंट में CSRF: यह क्या है, हमलों के प्रकार और सुरक्षा के तरीके

CSRF हमला क्या है?

CSRF (Cross-Site Request Forgery) — एक हमला है जहाँ हमलावर एक नकली अनुरोध बनाता है और पीड़ित के ब्राउज़र को इसे लक्ष्य सर्वर पर भेजने के लिए मजबूर करता है। सर्वर अनुरोध को निष्पादित करता है क्योंकि उसे उपयोगकर्ता के वर्तमान सत्र से मान्य कुकी क्रेडेंशियल प्राप्त होते हैं। हमला संभव है क्योंकि ब्राउज़र स्वचालित रूप से प्रत्येक अनुरोध में लक्ष्य डोमेन की कुकीज़ जोड़ता है, भले ही अनुरोध किस पेज से भेजा गया हो। उपयोगकर्ता हमलावर का पेज देख भी नहीं सकता — एक छिपा हुआ <img>, <form> या <iframe> दुर्भावनापूर्ण URL के साथ लोड करना पर्याप्त है। CSRF सीधे डेटा नहीं चुराता — हमला पीड़ित की ओर से कार्रवाई करता है (स्टेट-चेंजिंग ऑपरेशन), जैसे धन हस्तांतरण, पासवर्ड बदलना या खाता हटाना।

कौन से ऑपरेशन सबसे अधिक असुरक्षित हैं?

CSRF हमले केवल स्टेट-चेंजिंग ऑपरेशन को लक्षित करते हैं — GET अनुरोध साइड इफेक्ट के साथ, POST, PUT और DELETE। उदाहरण के लिए, व्यक्तिगत खाते में ईमेल पता बदलने का अनुरोध: यदि सर्वर उत्पत्ति की जाँच किए बिना अनुरोध स्वीकार करता है, तो हमलावर अपना ईमेल डाल सकता है और पासवर्ड रीसेट शुरू कर सकता है। हमला विशेष रूप से बैंकिंग सिस्टम, एडमिन पैनल और सोशल नेटवर्क के लिए खतरनाक है, जहाँ एक कार्रवाई के गंभीर परिणाम होते हैं। मोबाइल ऐप API जो प्रमाणीकरण के लिए कुकीज़ का उपयोग करते हैं, वे भी CSRF के प्रति संवेदनशील हैं यदि वे अतिरिक्त जाँच नहीं करते।

कौन जोखिम में है?

कोई भी वेब एप्लिकेशन और API जहाँ प्रमाणीकरण कुकीज़ पर आधारित है और सर्वर अनुरोध उत्पत्ति की जाँच नहीं करता, असुरक्षित है। मोबाइल एप्लिकेशन जो वेब फॉर्म के माध्यम से प्रमाणीकरण के लिए WebView का उपयोग करते हैं, वे भी जोखिम में हैं: ब्राउज़र घटक स्वचालित रूप से कुकीज़ भेजता है, और हमलावर पृष्ठभूमि लोडिंग के माध्यम से दुर्भावनापूर्ण अनुरोध इंजेक्ट कर सकता है। HackerOne (2025) के अनुसार, वेब एप्लिकेशन में सभी कमजोरियों की रिपोर्ट का लगभग 12% CSRF सुरक्षा की कमी से संबंधित है।

CSRF को खतरनाक क्या बनाता है?

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

CSRF हमला कैसे काम करता है?

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

<!-- छिपे फ़ॉर्म के माध्यम से CSRF हमले का उदाहरण -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

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

CSRF में ब्राउज़र की भूमिका

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

CSRF हमलों के मुख्य प्रकार

CSRF हमलों को दुर्भावनापूर्ण अनुरोध देने की विधि द्वारा वर्गीकृत किया जाता है। प्रत्येक प्रकार अनुरोध भेजने के लिए एक अलग HTML तत्व का उपयोग करता है, लेकिन सभी ब्राउज़र द्वारा स्वचालित कुकी भेजने पर निर्भर करते हैं। विधि का चुनाव हमलावर के लक्ष्यों पर निर्भर करता है: GET-आधारित हमलों में कम कोड की आवश्यकता होती है, POST-आधारित हमले कुछ सुरक्षाओं को अधिक विश्वसनीय रूप से बायपास करते हैं, और XMLHttpRequest-आधारित हमले हेडर में हेरफेर की अनुमति देते हैं।

GET-आधारित CSRF

सबसे सरल विधि: हमलावर एक पेज पर <img> रखता है जिसमें URL में अनुरोध पैरामीटर होते हैं। ब्राउज़र छवि लोड करता है और सर्वर को GET अनुरोध भेजता है। उदाहरण के लिए, <img src="https://api.example.com/delete?postId=123" /> एक रिकॉर्ड हटाता है यदि सर्वर GET के माध्यम से DELETE को संभालता है। स्पष्ट खतरे के बावजूद, कुछ API अभी भी हटाने या अपडेट करने के संचालन के लिए GET का उपयोग करते हैं।

POST-आधारित CSRF

यदि सर्वर केवल POST अनुरोध स्वीकार करता है, तो हमलावर POST विधि के साथ एक छिपा हुआ फॉर्म बनाता है और JavaScript के माध्यम से इसे स्वचालित रूप से सबमिट करता है। फॉर्म स्क्रीन पर प्रदर्शित नहीं होता (सभी <input> में type="hidden" है), और autofocus + .submit() उपयोगकर्ता के क्लिक के बिना ट्रिगर होता है। POST-आधारित हमले काम नहीं करते यदि सर्वर Content-Type हेडर की जाँच करता है, लेकिन अधिकांश API मानक application/x-www-form-urlencoded स्वीकार करते हैं।

XHR-आधारित CSRF (CORS के साथ)

XMLHttpRequest या Fetch API मनमाने हेडर के साथ अनुरोध भेजने की अनुमति देता है। यदि सर्वर ने CORS को बहुत व्यापक रूप से कॉन्फ़िगर किया है (Access-Control-Allow-Origin: *), तो हमलावर कोई भी अनुरोध भेज सकता है और प्रतिक्रिया पढ़ सकता है। हालाँकि, CSRF हमले के लिए प्रतिक्रिया पढ़ना आवश्यक नहीं है — कार्रवाई को निष्पादित करना पर्याप्त है। आधुनिक ब्राउज़र गैर-मानक अनुरोधों से पहले एक preflight अनुरोध OPTIONS भेजते हैं, जो XHR-आधारित CSRF को ब्लॉक कर सकता है यदि सर्वर सही ढंग से कॉन्फ़िगर किया गया हो।

मोबाइल एप्लिकेशन में CSRF

मोबाइल एप्लिकेशन वेबसाइटों की तुलना में CSRF के प्रति कम संवेदनशील हैं क्योंकि मूल एप्लिकेशन शायद ही कभी कुकी प्रमाणीकरण का उपयोग करते हैं। इसके बजाय, मोबाइल API अधिक बार Authorization हेडर (Bearer टोकन, JWT) में टोकन का उपयोग करते हैं। हालाँकि, ऐसे परिदृश्य हैं जहाँ CSRF हमला संभव है: वेब लॉगिन के साथ WebView, हाइब्रिड एप्लिकेशन और कुकी-आधारित सत्रों वाली API। TechCrunch (2025) के अनुसार, लगभग 18% सार्वजनिक मोबाइल ऐप API अभी भी सत्र कुकीज़ का समर्थन करते हैं।

WebView के माध्यम से CSRF

कई ऐप WebView में वेब पेज खोलते हैं — OAuth प्राधिकरण, भुगतान फॉर्म, सामग्री देखना। WebView ऐप के अंदर एक पूर्ण ब्राउज़र है जो सत्र कुकीज़ संग्रहीत करता है। यदि हमलावर WebView में अपना URL लोड करने का तरीका ढूंढता है (ओपन रीडायरेक्ट या डीप लिंक के माध्यम से), तो वह सामान्य ब्राउज़र की तरह ही CSRF हमला कर सकता है। सुरक्षा — महत्वपूर्ण संचालन के लिए WebView के बजाय Chrome Custom Tabs या SFSafariViewController का उपयोग करें।

JWT प्रमाणीकरण वाली API में CSRF

JWT टोकन आमतौर पर localStorage या ऐप की मेमोरी में संग्रहीत होते हैं और स्वचालित रूप से नहीं भेजे जाते — डेवलपर प्रत्येक अनुरोध में स्पष्ट रूप से Authorization हेडर जोड़ता है। यह क्लासिक CSRF हमले को असंभव बना देता है। हालाँकि, यदि ऐप JWT को कुकी में संग्रहीत करता है (दुर्लभ लेकिन संभव), तो जोखिम वापस आ जाता है। अतिरिक्त सुरक्षा — JWT को azp या aud claim के माध्यम से एक विशिष्ट अनुरोध उत्पत्ति से बांधना, जो किसी भिन्न डोमेन पर टोकन के उपयोग को रोकता है।

// Express में सर्वर-साइड CSRF टोकन सत्यापन का उदाहरण
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// लॉगिन पर CSRF टोकन जनरेट करना
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

CSRF से सुरक्षा के तरीके

आधुनिक CSRF सुरक्षा तीन स्तरों पर बनाई गई है: सर्वर-साइड CSRF टोकन, कुकीज़ के लिए SameSite विशेषता, और Origin हेडर की जाँच। इन विधियों का संयोजन UX को महत्वपूर्ण रूप से प्रभावित किए बिना 99% CSRF हमलों से सुरक्षा प्रदान करता है। दृष्टिकोण का चुनाव एप्लिकेशन आर्किटेक्चर पर निर्भर करता है: एक वेबसाइट को केवल SameSite=Lax की आवश्यकता हो सकती है, जबकि मोबाइल ऐप API को हेडर में टोकन की आवश्यकता होती है।

CSRF टोकन (सिंक्रोनाइज़र)

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

SameSite कुकी

कुकीज़ के लिए SameSite विशेषता क्रॉस-डोमेन अनुरोधों पर कुकी भेजने को प्रतिबंधित करती है। Lax मान केवल शीर्ष-स्तरीय नेविगेशन GET अनुरोधों के लिए कुकीज़ की अनुमति देता है — अधिकांश वेबसाइटों के लिए पर्याप्त। Strict सभी क्रॉस-डोमेन अनुरोधों के लिए कुकीज़ को ब्लॉक करता है, जिसमें नेविगेशन भी शामिल है: उपयोगकर्ता को किसी अन्य साइट से आने पर पुनः प्रमाणित करना होगा। Chrome Platform Status (2026) के अनुसार, SameSite=Lax सभी आधुनिक ब्राउज़रों में डिफ़ॉल्ट रूप से सक्षम है, जिसने CSRF हमलों की संख्या में 67% की कमी की है।

Origin और Referer की जाँच

सर्वर आने वाले अनुरोधों के Origin या Referer हेडर की जाँच कर सकता है। यदि अनुरोध किसी भिन्न डोमेन से आया है, तो इसे ब्लॉक कर दिया जाता है। Origin, Referer से अधिक विश्वसनीय है क्योंकि यह POST अनुरोधों में हमेशा मौजूद रहता है और ब्राउज़र नीतियों द्वारा अक्षम नहीं किया जा सकता। कार्यान्वयन: अनुमत उत्पत्तियों की एक श्वेत सूची, हेडर के वर्तमान मान से तुलना। यह विधि प्रभावी है लेकिन मोबाइल ऐप्स के साथ कठिन है, जहाँ Origin हेडर अनुपस्थित या नकली हो सकते हैं।

// Spring Boot में CSRF टोकन सत्यापन का उदाहरण
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit कुकी

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

• CSRF टोकन — स्वर्ण मानक: विश्वसनीय, समय-परीक्षित, सभी फ्रेमवर्क द्वारा समर्थित
• SameSite=Lax — वेब ऐप्स के लिए न्यूनतम सुरक्षा: मुफ्त, स्वचालित, कोई कोड आवश्यक नहीं
• Origin जाँच — एक अतिरिक्त परत: टोकन सत्यापन से पहले हमलों को ब्लॉक करती है
• Double Submit — सर्वर-साइड सत्रों के बिना REST API के लिए: HTTPS पर प्रभावी
• कस्टम हेडर — X-Requested-With: XMLHttpRequest सरल CSRF फॉर्म को ब्लॉक करता है

CSRF और XSS में अंतर

CSRF और XSS विभिन्न प्रकार के हमले हैं जिन्हें अक्सर भ्रमित किया जाता है। CSRF उपयोगकर्ता के ब्राउज़र में सर्वर के विश्वास का शोषण करता है: सर्वर हमलावर के आदेश को निष्पादित करता है क्योंकि अनुरोध मान्य कुकीज़ के साथ आता है। XSS सर्वर की सामग्री में ब्राउज़र के विश्वास का शोषण करता है: ब्राउज़र हमलावर द्वारा पेज में इंजेक्ट की गई स्क्रिप्ट को निष्पादित करता है। CSRF को लक्ष्य साइट पर कोड इंजेक्ट करने की आवश्यकता नहीं है — दूसरे डोमेन से अनुरोध भेजना पर्याप्त है। XSS, इसके विपरीत, पेज के HTML कोड में JavaScript इंजेक्ट करने का तरीका खोजने की आवश्यकता है। हालाँकि, XSS CSRF सुरक्षा को बायपास कर सकता है: इंजेक्ट की गई स्क्रिप्ट पेज से CSRF टोकन पढ़ती है और इसे अनुरोध के साथ भेजती है।

CSRF और XSS के बीच अंतर को समझना बहु-स्तरीय सुरक्षा बनाने के लिए महत्वपूर्ण है। CSRF टोकन XSS से रक्षा नहीं करते, और CSP (Content Security Policy) CSRF से रक्षा नहीं करती। केवल विधियों का संयोजन दोनों प्रकार के हमलों से एप्लिकेशन सुरक्षा सुनिश्चित करता है। WebView वाले मोबाइल ऐप्स में, जोखिम दोगुना हो जाता है, इसलिए डेवलपर्स को API अनुरोधों के लिए कम से कम CSRF टोकन और वेब सामग्री के लिए Content Security Policy लागू करने की सलाह दी जाती है।