موبائل ایپس میں Code Injection — یہ کیا ہے، حملوں کی اقسام اور تحفظ

Code Injection کیا ہے؟

Code Injection حملوں کا ایک طبقہ ہے جس میں حملہ آور ناقابل اعتماد ان پٹ ڈیٹا کے ذریعے ایپلیکیشن میں قابل عمل کوڈ داخل کرتا ہے۔ موبائل ایپلیکیشنز میں، ان پٹ فیلڈز، ڈیپ لنکس، پش نوٹیفکیشنز، QR کوڈز اور فائل کے تبادلے کے ذریعے حملہ ممکن ہے۔

OS سطح کے حملوں کے برعکس، Code Injection خود ایپلیکیشن کے کوڈ میں منطقی غلطیوں کا استحصال کرتا ہے: escape کی کمی، غیر محفوظ سٹرنگ جوڑ، یا بیرونی ڈیٹا ذرائع پر اعتماد۔ 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 پیرامیٹرز کے ذریعے منتقل ہوتا ہے اور ایک بار عمل میں آتا ہے۔ موبائل ایپلیکیشنز میں، WebView میں دوسرے صارفین کو دکھائے جانے والے تبصروں، جائزوں یا صارف کے مواد کے ذریعے Stored XSS خاص طور پر خطرناک ہے۔

تحفظ میں 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 سکیم ہینڈلنگ کے ذریعے ہوتے ہیں۔ ایک ایپلیکیشن جو تصدیق کے بغیر بیرونی ذرائع سے ڈیٹا قبول کرتی ہے، انجیکشن کے لیے کمزور ہو جاتی ہے۔ Apple Security Research (2025) کے مطابق، iOS ایپلیکیشنز میں تقریباً 12% کمزوریاں ناکافی ان پٹ ڈیٹا صفائی سے متعلق ہیں۔

دونوں پلیٹ فارمز کے لیے ایک مشترکہ ویکٹر مقامی اسٹوریج (SQLite، Realm، UserDefaults) کے ذریعے حملہ ہے۔ اگر کوئی بدنیتی پر مبنی ایپلیکیشن مشترکہ ڈائریکٹری میں ڈیٹا لکھ سکتی ہے، تو یہ کوڈ داخل کر سکتی ہے جو پڑھنے پر ہدف ایپلیکیشن کے ذریعے عمل میں آئے گا۔

ایک عام حملہ کے عمل میں تین مراحل شامل ہیں: reconnaissance — ایپلیکیشن کے ان پٹ پوائنٹس کا تجزیہ (فارم، ڈیپ لنکس، فائلیں)، انجیکشن — ملے ہوئے ان پٹ پوائنٹ کے ذریعے بدنیتی پر مبنی پے لوڈ کی ترسیل، اور استحصال — ڈیٹا یا فعالیت تک رسائی حاصل کرنے کے لیے انجیکشن کا نفاذ۔ اس چکر کو سمجھنا ڈویلپرز کو ہر مرحلے پر تحفظ ڈیزائن کرنے میں مدد کرتا ہے۔

کوڈ مثالیں: کمزور اور محفوظ نفاذ

آئیے 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 جیسی لائبریریاں عام منظرناموں کے لیے تیار توثیق کنندگان فراہم کرتی ہیں۔

دوسری سطح صفائی اور escape ہے: SQL استفسارات، HTML ٹیمپلیٹس یا شیل کمانڈز میں استعمال کرنے سے پہلے ڈیٹا کو تبدیل کرنا۔ پیرامیٹرائزڈ استفسارات SQL Injection کو مکمل طور پر ختم کرتی ہیں، اور HTML escape XSS کو روکتا ہے۔ Android پر، SQLite کے ساتھ کام کرنے کے لیے Room کا استعمال کریں — ایک ORM جو خود بخود bind پیرامیٹرز لاگو کرتا ہے۔

تیسری سطح مراعات کی کم سے کم کاری ہے: ایپلیکیشن کو کم سے کم ضروری اجازتوں کے ساتھ کام کرنا چاہیے۔ ڈیٹا بیس، فائل سسٹم اور انٹرپروسیس مواصلات کے لیے کم سے کم مراعات کے اصول کا استعمال کریں۔ iOS ایپلیکیشن سینڈ باکس کے ذریعے اس اصول کو لاگو کرتا ہے، اور Android اجازت ماڈل اور عمل کی تنہائی کے ذریعے۔

چوتھی سطح نگرانی اور ردعمل ہے: مشکوک کارروائیوں کی لاگنگ، بے ضابطگی کا پتہ لگانا اور حملوں کی تکرار پر خودکار بلاک کرنا۔ Firebase App Check جیسے اوزار سمجھوتہ شدہ کلائنٹس سے بیک اینڈ پر جعلی درخواستوں کا پتہ لگانے میں مدد کرتے ہیں۔ RASP (Runtime Application Self-Protection) کا انضمام رن ٹائم پر انجیکشن کو بلاک کرنے کی اجازت دیتا ہے۔

Google Project Zero (2025) کے مطالعے کے مطابق، ان چار سطحوں کا مجموعہ Code Injection کے کامیاب حملے کے خطرے کو 94% تک کم کرتا ہے۔ ڈویلپرز کو مشورہ دیا جاتا ہے کہ وہ کمزوریوں کی دریافت کے بعد شامل کرنے کے بجائے آرکیٹیکچر ڈیزائن کے مرحلے پر حفاظتی میکانزم لاگو کریں۔