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

प्रमुख खतरे: OWASP Mobile Top 10

OWASP Mobile Top 10 क्या है?

OWASP (Open Web Application Security Project) एक गैर-लाभकारी संगठन है जो सबसे खतरनाक मोबाइल सुरक्षा कमजोरियों की रैंकिंग प्रकाशित करता है। OWASP Mobile Top 10 एक सूची है जो डेवलपर्स को यह समझने में मदद करती है कि पहले किस पर ध्यान केंद्रित करना चाहिए। 2024 संस्करण में, असुरक्षित भंडारण, कमजोर प्रमाणीकरण और असुरक्षित नेटवर्क संचार से संबंधित समस्याएं रैंकिंग में शीर्ष पर हैं।

M1: असुरक्षित डेटा भंडारण — सबसे आम समस्या: पासवर्ड, टोकन और व्यक्तिगत डेटा बिना एन्क्रिप्शन के SharedPreferences, NSUserDefaults या स्थानीय फ़ाइलों में रह जाते हैं। M2: कमजोर प्रमाणीकरण — सर्वर-साइड सत्यापन की कमी, कमजोर पासवर्ड। M3: असुरक्षित नेटवर्क संचार — HTTPS की कमी या गलत SSL प्रमाणपत्र सत्यापन। M4 और M5 क्रिप्टोग्राफी और गलत API उपयोग से संबंधित हैं।

M6: असुरक्षित प्राधिकरण — एक उपयोगकर्ता अनुरोध में ID बदलकर दूसरे उपयोगकर्ता के डेटा तक पहुंच सकता है। M7: कोड इंजेक्शन (SQL Injection, XSS)। M8: ऐप हेरफेर — रिपैकेजिंग, कोड प्रतिस्थापन। M9 और M10 — तीसरे पक्ष की लाइब्रेरी के माध्यम से डेटा लीक और रिवर्स इंजीनियरिंग। इनमें से प्रत्येक खतरे के लिए सिद्ध प्रतिउपाय मौजूद हैं, और IT Sectr में हम 2017 से सभी परियोजनाओं में उन्हें लागू कर रहे हैं।

Man-in-the-Middle (MITM) हमले

MITM हमला तब होता है जब कोई हमलावर एप्लिकेशन और सर्वर के बीच ट्रैफ़िक को इंटरसेप्ट करता है। यह DNS स्पूफिंग, ARP स्पूफिंग या असुरक्षित Wi-Fi नेटवर्क से कनेक्ट करके संभव है। सुरक्षा के लिए SSL/TLS प्रमाणपत्र और Certificate Pinning का उपयोग किया जाता है।

Certificate Pinning एक तंत्र है जिसमें एप्लिकेशन सत्यापित करता है कि सर्वर प्रमाणपत्र एप्लिकेशन कोड में पहले से संग्रहीत प्रमाणपत्र से मेल खाता है। भले ही हमलावर प्रॉक्सी (जैसे Burp Suite) के माध्यम से प्रमाणपत्र बदल दे, एप्लिकेशन कनेक्शन को अस्वीकार कर देगा। Pinning दो प्रकार का होता है: Public Key Pinning और Certificate Hash Pinning।

एन्क्रिप्शन और हैशिंग: AES, RSA, SSL/TLS

सममित एन्क्रिप्शन: AES

AES (Advanced Encryption Standard) एक सममित एन्क्रिप्शन एल्गोरिदम है, जो डिवाइस पर डेटा सुरक्षा की नींव है। AES डेटा को एन्क्रिप्ट और डिक्रिप्ट करने के लिए एक ही कुंजी का उपयोग करता है। AES 128, 192 या 256 बिट की कुंजियों का समर्थन करता है। मोबाइल डेवलपमेंट में, AES-256 का उपयोग डिवाइस पर डेटा (फ़ाइलें, कैश, स्थानीय डेटाबेस में रिकॉर्ड) को एन्क्रिप्ट करने के लिए किया जाता है।

AES मोड: GCM (अनुशंसित) — डेटा प्रमाणीकरण प्रदान करता है, CBC — ब्लॉक चेनिंग के साथ बेसिक मोड, ECB — असुरक्षित, इसका उपयोग न करें। iOS के लिए, AES CommonCrypto (CCOptions) के माध्यम से उपलब्ध है, Android के लिए — Java Cryptography Architecture (JCA) में Cipher के माध्यम से। महत्वपूर्ण: एन्क्रिप्शन कुंजी को कभी भी एप्लिकेशन कोड में संग्रहीत नहीं किया जाना चाहिए — Keychain/Keystore का उपयोग करें।

असममित एन्क्रिप्शन: RSA — कुंजियों की एक जोड़ी (सार्वजनिक और निजी) का उपयोग करता है। RSA का उपयोग छोटी मात्रा में डेटा को एन्क्रिप्ट करने के लिए किया जाता है — आमतौर पर क्लाइंट और सर्वर के बीच सममित कुंजी के आदान-प्रदान के लिए। न्यूनतम RSA कुंजी लंबाई 2048 बिट है (4096 अनुशंसित)। iOS पर, RSA Security Framework (SecKeyCreateRandomKey) के माध्यम से उपलब्ध है, Android पर — Android Keystore में KeyPairGenerator के माध्यम से।

हैशिंग और SSL/TLS

हैशिंग (SHA-256, SHA-3) डेटा का एक निश्चित लंबाई की स्ट्रिंग में अपरिवर्तनीय रूपांतरण है। हैश का उपयोग डेटा अखंडता सत्यापन और पासवर्ड भंडारण के लिए किया जाता है। पासवर्ड के लिए, bcrypt, scrypt या Argon2 का उपयोग करना सुनिश्चित करें — सादा SHA-256 रेनबो टेबल हमलों के लिए असुरक्षित है। SSL/TLS क्लाइंट और सर्वर के बीच नेटवर्क ट्रैफ़िक को एन्क्रिप्ट करने का एक प्रोटोकॉल है। आधुनिक मानक TLS 1.3 है, जो Perfect Forward Secrecy (PFS) प्रदान करता है।

TLS 1.3 अपने पूर्ववर्तियों की तुलना में तेज़ है: हैंडशेक में दो के बजाय एक राउंड ट्रिप लगता है। Android पर, न्यूनतम TLS संस्करण SSLSocket के माध्यम से कॉन्फ़िगर किया जाता है, iOS पर — ATS (App Transport Security) के माध्यम से, जो डिफ़ॉल्ट रूप से TLS 1.2 या उच्चतर की आवश्यकता होती है। ATS को केवल विशिष्ट डोमेन के लिए औचित्य के साथ अक्षम किया जा सकता है।

सुरक्षित भंडारण: Keychain और Keystore

iOS: Keychain

Keychain (कीचेन) iOS / macOS में पासवर्ड, एन्क्रिप्शन कुंजियों, प्रमाणपत्रों और टोकन के लिए एक सुरक्षित भंडार है। Keychain में डेटा प्रत्येक डिवाइस के लिए अद्वितीय हार्डवेयर कुंजी से एन्क्रिप्ट किया जाता है। Keychain तक पहुंच Security Framework (SecItemAdd, SecItemCopyMatching) के माध्यम से नियंत्रित की जाती है। डिवाइस लॉक होने पर Keychain स्वचालित रूप से लॉक हो जाता है और Secure Enclave का उपयोग करके एन्क्रिप्ट किया जाता है।

Android: Keystore

Android Keystore क्रिप्टोग्राफ़िक कुंजियों के लिए एक सिस्टम स्टोरेज है, जो एप्लिकेशन से अलग है। Android 6.0 (API 23) से शुरू होकर, Keystore सुरक्षा चिप वाले उपकरणों पर हार्डवेयर समर्थन (TEE — Trusted Execution Environment) का उपयोग करता है। Keystore में कुंजियाँ कभी भी सुरक्षित क्षेत्र नहीं छोड़ती हैं — एप्लिकेशन को केवल एन्क्रिप्शन और हस्ताक्षर संचालन के लिए एक हैंडल मिलता है।

SharedPreferences और NSUserDefaults संवेदनशील डेटा संग्रहीत करने के लिए डिज़ाइन नहीं किए गए हैं — वे सादे टेक्स्ट में जानकारी संग्रहीत करते हैं। डेटा सुरक्षा के लिए, EncryptedSharedPreferences (Android) का उपयोग करें या UserDefaults (iOS) में सहेजने से पहले डेटा को एन्क्रिप्ट करें। IT Sectr में, हम एक्सेस टोकन और पासवर्ड के लिए हमेशा Keychain और Keystore का उपयोग करते हैं।

प्रमाणीकरण: OAuth 2.0, JWT और बायोमेट्रिक्स

OAuth 2.0 और OpenID Connect

OAuth 2.0 एक प्रत्यायोजित प्राधिकरण प्रोटोकॉल है जो पासवर्ड प्रेषित किए बिना उपयोगकर्ता संसाधनों तक सुरक्षित पहुंच प्रदान करता है। मोबाइल एप्लिकेशन में, सबसे अधिक उपयोग PKCE (Proof Key for Code Exchange) के साथ Authorization Code Flow किया जाता है। PKCE प्राधिकरण कोड के अवरोधन को रोकता है — मोबाइल एप्लिकेशन के लिए एक अनिवार्य आवश्यकता।

OpenID Connect (OIDC) उपयोगकर्ता प्रमाणीकरण के लिए OAuth 2.0 के ऊपर एक एक्सटेंशन है। OIDC JWT प्रारूप में एक ID Token जोड़ता है जिसमें उपयोगकर्ता की जानकारी (नाम, ईमेल, आईडी) होती है। OAuth 2.0 + OIDC प्रवाह में शामिल हैं: उपयोगकर्ता को लॉगिन पेज पर रीडायरेक्ट करना, प्राधिकरण कोड प्राप्त करना, टोकन के लिए कोड का आदान-प्रदान (access + refresh + id), API अनुरोधों के लिए एक्सेस टोकन का उपयोग करना।

JWT: एक्सेस, रिफ्रेश और सत्र टोकन

JWT (JSON Web Token) एक कॉम्पैक्ट, URL-सुरक्षित टोकन प्रारूप है जिसमें JSON प्रारूप में दावे (claims) होते हैं। JWT तीन भागों से बना होता है: हेडर (प्रकार और हस्ताक्षर एल्गोरिदम), पेलोड (डेटा) और हस्ताक्षर। एक्सेस टोकन API तक पहुंच के लिए एक अल्पकालिक टोकन (15-60 मिनट) है। रिफ्रेश टोकन पुनः लॉगिन किए बिना नया एक्सेस टोकन प्राप्त करने के लिए एक दीर्घकालिक टोकन (दिन/सप्ताह) है।

सत्र टोकन एक पारंपरिक दृष्टिकोण है जहां सर्वर सत्र को डेटाबेस या Redis में संग्रहीत करता है, और क्लाइंट को एक यादृच्छिक पहचानकर्ता मिलता है। मोबाइल डेवलपमेंट में, JWT को प्राथमिकता दी जाती है: इसे सर्वर-साइड सत्र भंडारण की आवश्यकता नहीं होती है, इसमें सभी जानकारी स्वयं होती है और इसे सत्यापित करना आसान होता है। हालाँकि, JWT को तुरंत रद्द नहीं किया जा सकता है — यह एक समझौता है जिसे एक्सेस टोकन के छोटे जीवनकाल और रिफ्रेश टोकन के उपयोग से हल किया जाता है।

बायोमेट्रिक प्रमाणीकरण

iOS पर Face ID और Touch ID, Android पर फिंगरप्रिंट प्रमाणीकरण — बायोमेट्रिक प्रमाणीकरण विधियाँ जो उपयोगकर्ता की अद्वितीय भौतिक विशेषताओं का उपयोग करती हैं। iOS पर, बायोमेट्रिक्स LocalAuthentication (LAContext) के माध्यम से काम करता है, Android पर — BiometricPrompt (Android 9+) या FingerprintManager (पदावनत) के माध्यम से। बायोमेट्रिक्स का उपयोग ऐप को अनलॉक करने, भुगतान की पुष्टि करने और संरक्षित डेटा तक पहुंचने के लिए किया जाता है।

महत्वपूर्ण बारीकियाँ: बायोमेट्रिक्स एक सुविधाजनक UX है, लेकिन सर्वर प्रमाणीकरण का विकल्प नहीं है। सफल बायोमेट्रिक सत्यापन के बाद, एप्लिकेशन को सर्वर से एक एक्सेस टोकन प्राप्त करना चाहिए। Android पर, सुनिश्चित करें कि डिवाइस क्लास 3 (मजबूत) बायोमेट्रिक्स का उपयोग करता है, न कि केवल कैमरा-आधारित चेहरे की पहचान (क्लास 1)।

कोड सुरक्षा: ProGuard, R8 और Root Detection

ऑबफस्केशन: ProGuard और R8

ProGuard Android के लिए Java बाइटकोड का ऑबफस्केशन, संपीड़न और अनुकूलन उपकरण है, जो रिवर्स इंजीनियरिंग के खिलाफ कोड सुरक्षा बढ़ाता है। R8 इसका उत्तराधिकारी है, जो Android Studio 3.4 से Gradle में एकीकृत है। R8 चार कार्य करता है: संपीड़न (अप्रयुक्त क्लास और विधियों को हटाता है), अनुकूलन (विधियों को इनलाइन करता है, कोड को सरल करता है), ऑबफस्केशन (क्लास और विधियों को छोटे नामों में बदलता है) और पूर्व-सत्यापन (बाइटकोड जांच)।

DexGuard उन्नत सुरक्षा के साथ ProGuard का एक व्यावसायिक संस्करण है: स्ट्रिंग एन्क्रिप्शन, संसाधन ऑबफस्केशन, रिपैकेजिंग से सुरक्षा, APK अखंडता नियंत्रण। अधिकांश परियोजनाओं के लिए, R8 पर्याप्त है, लेकिन वित्तीय और बैंकिंग अनुप्रयोगों के लिए, DexGuard अतिरिक्त सुरक्षा परत प्रदान करता है। R8 build.gradle के माध्यम से सक्षम किया जाता है: minifyEnabled = true और proguardFiles।

रूट और जेलब्रेक डिटेक्शन

Root Detection (Android) और Jailbreak Detection (iOS) ऐसे तंत्र हैं जो जांचते हैं कि डिवाइस पर सुपरयूज़र विशेषाधिकार प्राप्त हुए हैं या नहीं। समझौता किए गए उपकरणों पर, प्रक्रिया मेमोरी को पढ़ना, ट्रैफ़िक को इंटरसेप्ट करना और कोड को बदलना संभव है। Android पर जांच के लिए, SU बाइनरी फ़ाइल की उपस्थिति, परीक्षण हस्ताक्षर कुंजियाँ और गैर-मानक बिल्ड फ़्लैग का उपयोग किया जाता है।

RASP (Runtime Application Self-Protection) एक तकनीक है जो निष्पादन के दौरान एप्लिकेशन की रक्षा करती है। RASP डिबगिंग, रिपैकेजिंग, कोड इंजेक्शन के प्रयासों का पता लगाता है और खतरों का पता चलने पर एप्लिकेशन को समाप्त कर देता है। RASP समाधानों के उदाहरण: Dexter, Guardsquare, Promon। RASP रनटाइम पर काम करता है और विसंगतियों पर प्रतिक्रिया करता है — स्थिर ऑबफस्केशन के विपरीत, जो निष्पादन से पहले कोड की रक्षा करता है।

रिवर्स इंजीनियरिंग संकलित एप्लिकेशन से स्रोत कोड को पुनर्प्राप्त करने की प्रक्रिया है। उपकरण: JADX (APK डीकंपाइलर), Ghidra, IDA Pro, Hopper। रिवर्स इंजीनियरिंग के खिलाफ सुरक्षा ऑबफस्केशन, स्ट्रिंग एन्क्रिप्शन, अखंडता जांच और Root Detection का संयोजन है। कोई पूर्ण सुरक्षा नहीं है — लक्ष्य हमलावर के लिए रिवर्स इंजीनियरिंग को पर्याप्त महंगा बनाना है।