मोबाइल ऐप्स में Code Injection — यह क्या है, हमलों के प्रकार और सुरक्षा

Code Injection क्या है?

Code Injection हमलों का एक वर्ग है जिसमें हमलावर अविश्वसनीय इनपुट डेटा के माध्यम से एप्लिकेशन में निष्पादन योग्य कोड डालता है। मोबाइल एप्लिकेशन में, इनपुट फ़ील्ड, डीप लिंक, पुश नोटिफिकेशन, QR कोड और फ़ाइल एक्सचेंज के माध्यम से हमला संभव है।

OS-स्तरीय हमलों के विपरीत, Code Injection एप्लिकेशन के स्वयं के कोड में तार्किक त्रुटियों का शोषण करता है: एस्केपिंग की कमी, असुरक्षित स्ट्रिंग कॉन्केटनेशन या बाहरी डेटा स्रोतों पर भरोसा। Positive Technologies (2025) की रिपोर्ट के अनुसार, वित्तीय क्षेत्र में मोबाइल एप्लिकेशन में सभी कमजोरियों का 23% इंजेक्शन हैं।

Code Injection का मुख्य खतरा पूर्ण डेटा समझौता है: हमलावर डेटाबेस, डिवाइस फ़ाइल सिस्टम या अन्य उपयोगकर्ताओं के खातों तक पहुंच प्राप्त कर सकता है। भुगतान डेटा या चिकित्सा जानकारी से निपटने वाले मोबाइल एप्लिकेशन के लिए, परिणाम गंभीर हो सकते हैं।

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

मोबाइल ऐप्स में Code Injection के मुख्य प्रकार

Code Injection के वर्गीकरण में मोबाइल विकास के संदर्भ में तीन मुख्य प्रकार के हमले शामिल हैं। प्रत्येक प्रकार एप्लिकेशन के विभिन्न घटकों का शोषण करता है और विशिष्ट सुरक्षा विधियों की आवश्यकता होती है।

मोबाइल ऐप्स में SQL Injection

SQL Injection (SQLi) स्थानीय या दूरस्थ डेटाबेस में क्वेरी पैरामीटर के माध्यम से दुर्भावनापूर्ण SQL कोड का इंजेक्शन है। मोबाइल एप्लिकेशन में, कमजोरी तब उत्पन्न होती है जब डिवाइस पर SQLite के साथ असुरक्षित रूप से काम किया जाता है या स्ट्रिंग कॉन्केटनेशन के साथ REST API के लिए HTTP अनुरोध बनाए जाते हैं।

एक विशिष्ट हमला वेक्टर एक खोज या फ़िल्टर फ़ील्ड है जिसका मान सीधे SQL क्वेरी में डाला जाता है। यदि डेवलपर पैरामीटराइज़्ड क्वेरी के बजाय कच्चे कॉन्केटनेशन का उपयोग करता है, तो हमलावर 1' OR '1'='1 जैसी स्ट्रिंग पास कर सकता है। OWASP Mobile Top 10 (2024) के अनुसार, SQL Injection असुरक्षित डेटा भंडारण श्रेणी में मोबाइल एप्लिकेशन में दूसरी सबसे लगातार गंभीर कमजोरी बनी हुई है।

SQLi से सुरक्षा तीन स्तरों पर बनाई गई है: पैरामीटराइज़्ड क्वेरी का उपयोग (Java में PreparedStatement, Android में bindArgs के साथ rawQuery), क्लाइंट और सर्वर साइड पर इनपुट सत्यापन, और न्यूनतम डेटाबेस विशेषाधिकार।

WebView में Cross-Site Scripting (XSS)

मोबाइल एप्लिकेशन में XSS हमले WebView घटक पर लक्षित होते हैं — एक अंतर्निहित ब्राउज़र जो HTML सामग्री प्रदर्शित करता है। यदि कोई एप्लिकेशन स्वच्छीकरण के बिना WebView में बाहरी स्रोतों से डेटा लोड करता है, तो हमलावर JavaScript कोड इंजेक्ट कर सकता है जो एप्लिकेशन संदर्भ में निष्पादित होता है।

XSS के दो उपप्रकार हैं: Stored XSS — दुर्भावनापूर्ण स्क्रिप्ट सर्वर पर सहेजी जाती है और प्रत्येक पृष्ठ दृश्य पर निष्पादित होती है, और Reflected XSS — कोड URL या POST पैरामीटर के माध्यम से पारित किया जाता है और एक बार निष्पादित होता है। मोबाइल एप्लिकेशन में, टिप्पणियों, समीक्षाओं या उपयोगकर्ता सामग्री के माध्यम से Stored XSS जो WebView में अन्य उपयोगकर्ताओं को प्रदर्शित होती है, विशेष रूप से खतरनाक है।

सुरक्षा में WebView में JavaScript को अक्षम करना (यदि आवश्यक नहीं है), Content Security Policy (CSP) का उपयोग करना, और Android के लिए Jsoup या iOS के लिए SwiftSoup जैसी लाइब्रेरी के माध्यम से HTML सामग्री को स्वच्छ करना शामिल है।

Intent और Shell के माध्यम से Command Injection

Command Injection Runtime.exec(), ProcessBuilder या NSTask के अस्वच्छ कॉल के माध्यम से डिवाइस पर सिस्टम कमांड का निष्पादन है। मोबाइल एप्लिकेशन में, हमला संभव है यदि एप्लिकेशन शेल कमांड या क्रियाओं वाले Intent में उपयोगकर्ता डेटा पास करता है।

सबसे कमजोर क्षेत्र फ़ाइल रूपांतरण फ़ंक्शन, मीडिया प्रोसेसिंग (ffmpeg, ImageMagick) और तृतीय-पक्ष लाइब्रेरी स्थापना हैं। हमलावर पाइप या रीडायरेक्ट कैरेक्टर वाला कमांड पास कर सकता है जो डिवाइस पर मनमाना कोड निष्पादित करता है। Android सैंडबॉक्स के माध्यम से शेल एक्सेस को आंशिक रूप से प्रतिबंधित करता है, लेकिन रूट एक्सेस या PrivEsc शोषण वाले एप्लिकेशन से समझौता किया जा सकता है।

अनुशंसित सुरक्षा उपयोगकर्ता डेटा प्रोसेसिंग के लिए Runtime.exec() का पूर्ण परित्याग, सुरक्षित API वाली लाइब्रेरी का उपयोग और बाहरी प्रक्रियाओं का सख्त अलगाव है।

Android और iOS पर कोड इंजेक्शन कैसे काम करता है

Code Injection का तंत्र आर्किटेक्चरल अंतर के कारण Android और iOS प्लेटफ़ॉर्म पर भिन्न होता है। Android पर, इंजेक्शन अक्सर Intent से जुड़े होते हैं — एक सिस्टम संदेश जो एप्लिकेशन घटकों के बीच पारित किया जाता है। हमलावर SQL कोड या शेल कमांड वाले एक्स्ट्रा डेटा के साथ एक दुर्भावनापूर्ण Intent भेज सकता है।

iOS पर, हमले अक्सर इंटरप्रोसेस कम्युनिकेशन (XPC) तंत्र, यूनिवर्सल लिंक और URL Scheme हैंडलिंग के माध्यम से होते हैं। एक एप्लिकेशन जो बिना सत्यापन के बाहरी स्रोतों से डेटा स्वीकार करता है, इंजेक्शन के लिए कमजोर हो जाता है। Apple Security Research (2025) के अनुसार, iOS एप्लिकेशन में लगभग 12% कमजोरियां अपर्याप्त इनपुट डेटा स्वच्छीकरण से संबंधित हैं।

दोनों प्लेटफ़ॉर्म के लिए एक सामान्य वेक्टर स्थानीय भंडारण (SQLite, Realm, UserDefaults) के माध्यम से हमला है। यदि कोई दुर्भावनापूर्ण एप्लिकेशन साझा निर्देशिका में डेटा लिख सकता है, तो वह कोड इंजेक्ट कर सकता है जो पढ़ने पर लक्ष्य एप्लिकेशन द्वारा निष्पादित किया जाएगा।

एक विशिष्ट हमला प्रक्रिया में तीन चरण शामिल हैं: टोही — एप्लिकेशन के इनपुट बिंदुओं का विश्लेषण (फॉर्म, डीप लिंक, फ़ाइलें), इंजेक्शन — मिले इनपुट बिंदु के माध्यम से दुर्भावनापूर्ण पेलोड की डिलीवरी, और शोषण — डेटा या कार्यक्षमता तक पहुंच प्राप्त करने के लिए इंजेक्शन का निष्पादन। इस चक्र को समझना डेवलपर्स को प्रत्येक चरण में सुरक्षा डिज़ाइन करने में मदद करता है।

कोड उदाहरण: असुरक्षित और सुरक्षित कार्यान्वयन

आइए Android के लिए Kotlin और iOS के लिए Swift में Code Injection के विशिष्ट उदाहरण देखें। प्रत्येक उदाहरण एक कमजोर पैटर्न और उसका सुरक्षित विकल्प दिखाता है।

SQL Injection: Kotlin में कमजोर कोड

पहला उदाहरण उपयोगकर्ता इनपुट के साथ क्वेरी स्ट्रिंग का सीधा कॉन्केटनेशन है। userInput = "1' OR '1'='1" मान के साथ, क्वेरी एक के बजाय तालिका की सभी पंक्तियाँ लौटाती है।

// असुरक्षित: स्ट्रिंग कॉन्केटनेशन
fun getUserById(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = " + userInput
    return db.rawQuery(query, null)
}

// सुरक्षित: पैरामीटराइज़्ड क्वेरी
fun getUserByIdSafe(userInput: String): List<User> {
    val db = openOrCreateDatabase()
    val query = "SELECT * FROM users WHERE id = ?"
    return db.rawQuery(query, arrayOf(userInput))
}

WebView में XSS सुरक्षा: iOS के लिए Swift

दूसरा उदाहरण WKWebView में उपयोगकर्ता HTML सामग्री की गलत और सही लोडिंग दर्शाता है। SwiftSoup का उपयोग रेंडरिंग से पहले दुर्भावनापूर्ण स्क्रिप्ट को हटाने की अनुमति देता है।

// असुरक्षित: प्रत्यक्ष HTML लोडिंग
let webView = WKWebView()
let html = "<div>\(userComment)</div>"
webView.loadHTMLString(html, baseURL: nil)

// सुरक्षित: SwiftSoup के माध्यम से स्वच्छीकरण
import SwiftSoup
let cleanHtml = try SwiftSoup.clean(
    userComment,
    Whitelist.basic()
)
webView.loadHTMLString(cleanHtml, baseURL: nil)

Command Injection: Kotlin में शेल हमलों से सुरक्षा

तीसरा उदाहरण उपयोगकर्ता तर्कों के साथ Runtime.exec() को कॉल करने का खतरा और एक निश्चित API वाली लाइब्रेरी के माध्यम से सुरक्षित विकल्प है।

// असुरक्षित: उपयोगकर्ता इनपुट के साथ शेल कमांड
fun convertVideo(inputPath: String) {
    val cmd = "ffmpeg -i $inputPath -vcodec libx264 output.mp4"
    Runtime.getRuntime().exec(cmd)
}

// सुरक्षित: आर्गुमेंट आइसोलेशन
fun convertVideoSafe(inputPath: String) {
    val cmd = listOf(
        "ffmpeg", "-i", inputPath,
        "-vcodec", "libx264", "output.mp4"
    )
    ProcessBuilder(cmd).start()
}

मोबाइल ऐप्स को इंजेक्शन से बचाने के तरीके

Code Injection से सुरक्षा के लिए कोड, बुनियादी ढांचे और विकास प्रक्रियाओं को कवर करने वाले एक व्यवस्थित दृष्टिकोण की आवश्यकता है। कोई एकल विधि पूर्ण सुरक्षा की गारंटी नहीं देती — प्रथाओं के संयोजन की आवश्यकता है।

पहला स्तर रोकथाम है: सभी इनपुट डेटा का सख्त सत्यापन। प्रत्येक फ़ील्ड जो एप्लिकेशन उपयोगकर्ता, किसी अन्य एप्लिकेशन या नेटवर्क से प्राप्त करता है, उसके प्रकार, लंबाई और प्रारूप की जाँच की जानी चाहिए। OWASP ESAPI जैसी लाइब्रेरी सामान्य परिदृश्यों के लिए तैयार सत्यापनकर्ता प्रदान करती हैं।

दूसरा स्तर स्वच्छीकरण और एस्केपिंग है: SQL क्वेरी, HTML टेम्पलेट या शेल कमांड में उपयोग करने से पहले डेटा को रूपांतरित करना। पैरामीटराइज़्ड क्वेरी SQL Injection को पूरी तरह से समाप्त करती हैं, और HTML एस्केपिंग XSS को रोकती है। Android पर, SQLite के साथ काम करने के लिए Room का उपयोग करें — एक ORM जो स्वचालित रूप से बाइंड पैरामीटर लागू करता है।

तीसरा स्तर विशेषाधिकार न्यूनीकरण है: एप्लिकेशन को न्यूनतम आवश्यक अनुमतियों के साथ काम करना चाहिए। डेटाबेस, फ़ाइल सिस्टम और इंटरप्रोसेस संचार के लिए न्यूनतम विशेषाधिकार के सिद्धांत का उपयोग करें। iOS इस सिद्धांत को एप्लिकेशन सैंडबॉक्स के माध्यम से लागू करता है, और Android अनुमति मॉडल और प्रक्रिया अलगाव के माध्यम से।

चौथा स्तर निगरानी और प्रतिक्रिया है: संदिग्ध संचालन की लॉगिंग, विसंगति का पता लगाना और हमलों की पुनरावृत्ति पर स्वचालित अवरोधन। Firebase App Check जैसे उपकरण समझौता किए गए क्लाइंट से बैकएंड पर नकली अनुरोधों का पता लगाने में मदद करते हैं। RASP (Runtime Application Self-Protection) का एकीकरण रनटाइम पर इंजेक्शन को अवरुद्ध करने की अनुमति देता है।

Google Project Zero (2025) के अध्ययन के अनुसार, इन चार स्तरों का संयोजन Code Injection के सफल हमले के जोखिम को 94% तक कम कर देता है। डेवलपर्स को कमजोरी की खोज के बाद जोड़ने के बजाय आर्किटेक्चर डिज़ाइन चरण में सुरक्षा तंत्र लागू करने की सिफारिश की जाती है।