تزریق کد در اپلیکیشن‌های موبایل — چیست، انواع حملات و محافظت

تزریق کد چیست؟

تزریق کد — دسته‌ای از حملات است که در آن مهاجم کد اجرایی را از طریق داده‌های ورودی غیرقابل اعتماد به اپلیکیشن تزریق می‌کند. در اپلیکیشن‌های موبایل، حمله از طریق فیلدهای ورودی، deep link‌ها، اعلان‌های push، کدهای QR و تبادل فایل امکان‌پذیر است.

برخلاف حملات سطح سیستم‌عامل، تزریق کد از خطاهای منطقی در کد خود اپلیکیشن بهره می‌برد: عدم escape کردن، الحاق ناامن رشته‌ها یا اعتماد به منابع داده خارجی. طبق گزارش Positive Technologies (2025)، تزریق‌ها 23٪ از تمام آسیب‌پذیری‌های اپلیکیشن‌های موبایل بخش مالی را تشکیل می‌دهند.

خطر اصلی تزریق کد — به خطر افتادن کامل داده‌ها: مهاجم می‌تواند به پایگاه داده، سیستم فایل دستگاه یا حساب‌های سایر کاربران دسترسی پیدا کند. برای اپلیکیشن‌های موبایلی که با داده‌های پرداخت یا اطلاعات پزشکی کار می‌کنند، عواقب می‌تواند بحرانی باشد.

توسعه‌دهنده باید انواع تزریق را درک کرده و مکانیسم‌های محافظتی را در تمام سطوح — از ورود داده تا نمایش و ذخیره‌سازی — به کار گیرد. فریمورک‌های مدرن ابزارهای محافظتی داخلی ارائه می‌دهند، اما استفاده از آنها نیازمند رویکرد آگاهانه است.

انواع اصلی تزریق کد در اپلیکیشن‌های موبایل

طبقه‌بندی تزریق کد شامل سه نوع اصلی حمله در زمینه توسعه موبایل است. هر نوع از اجزای مختلف اپلیکیشن بهره می‌برد و نیازمند روش‌های محافظتی خاصی است.

SQL Injection در اپلیکیشن‌های موبایل

SQL Injection (SQLi) — تزریق کد SQL مخرب از طریق پارامترهای پرس و جو به پایگاه داده محلی یا راه دور. در اپلیکیشن‌های موبایل، آسیب‌پذیری هنگام کار ناامن با SQLite روی دستگاه یا هنگام ساخت درخواست‌های HTTP به REST API با الحاق رشته‌ها ایجاد می‌شود.

بردار حمله معمولی — فیلد جستجو یا فیلتر که مقدار آن مستقیماً در پرس و جوی SQL قرار می‌گیرد. اگر توسعه‌دهنده به جای پرس و جوهای پارامتری از الحاق مستقیم استفاده کند، مهاجم می‌تواند رشته‌ای مانند 1' OR '1'='1 ارسال کند. طبق OWASP Mobile Top 10 (2024)، SQL Injection دومین آسیب‌پذیری بحرانی رایج در اپلیکیشن‌های موبایل در دسته ذخیره‌سازی ناامن داده‌ها باقی می‌ماند.

محافظت در برابر SQLi بر سه سطح استوار است: استفاده از پرس و جوهای پارامتری (PreparedStatement در Java، rawQuery با bindArgs در Android)، اعتبارسنجی داده‌های ورودی در سمت کلاینت و سرور، و حداقل مجوزهای پایگاه داده.

Cross-Site Scripting (XSS) در WebView

حملات XSS در اپلیکیشن‌های موبایل متوجه کامپوننت WebView — مرورگر داخلی که محتوای HTML را نمایش می‌دهد — هستند. اگر اپلیکیشن داده‌هایی را از منابع خارجی بدون پاکسازی در WebView بارگذاری کند، مهاجم می‌تواند کد JavaScript تزریق کند که در زمینه اپلیکیشن اجرا می‌شود.

دو زیرنوع XSS وجود دارد: Stored XSS — اسکریپت مخرب روی سرور ذخیره شده و در هر نمایش صفحه اجرا می‌شود؛ Reflected XSS — کد از طریق URL یا پارامترهای POST ارسال شده و یک بار اجرا می‌شود. در اپلیکیشن‌های موبایل، Stored XSS از طریق نظرات، بازخوردها یا محتوای کاربری که در WebView به سایر کاربران نمایش داده می‌شود بسیار خطرناک است.

محافظت شامل غیرفعال کردن JavaScript در WebView در صورت عدم نیاز، استفاده از Content Security Policy (CSP) و پاکسازی محتوای HTML از طریق کتابخانه‌هایی مانند Jsoup برای Android یا SwiftSoup برای iOS است.

Command Injection از طریق Intent و Shell

Command Injection — اجرای دستورات سیستم روی دستگاه از طریق فراخوانی‌های محافظت‌نشده Runtime.exec()، ProcessBuilder یا NSTask. در اپلیکیشن‌های موبایل، حمله زمانی ممکن است که اپلیکیشن داده‌های کاربر را به دستورات shell یا Intent‌ها با اقدامات ارسال کند.

آسیب‌پذیرترین مکان‌ها — توابع تبدیل فایل، کار با رسانه (ffmpeg، ImageMagick) و نصب کتابخانه‌های خارجی. مهاجم می‌تواند دستوری با نماد لوله یا redirect ارسال کند که کد دلخواه را روی دستگاه اجرا کند. Android تا حدی دسترسی shell را از طریق sandbox محدود می‌کند، اما اپلیکیشن‌های دارای دسترسی root یا بهره‌برداری‌های PrivEsc ممکن است به خطر بیفتند.

محافظت توصیه‌شده — کنار گذاشتن کامل Runtime.exec() برای پردازش داده‌های کاربر، استفاده از کتابخانه‌های دارای API امن و جداسازی دقیق فرآیندهای خارجی.

تزریق کد در Android و iOS چگونه کار می‌کند

مکانیسم تزریق کد در پلتفرم‌های Android و iOS به دلیل تفاوت‌های معماری متفاوت است. در Android، تزریق‌ها اغلب با Intent — پیام سیستمی که بین اجزای اپلیکیشن منتقل می‌شود — مرتبط هستند. مهاجم می‌تواند Intent مخربی با داده‌های extra حاوی کد SQL یا دستورات shell ارسال کند.

در iOS، حملات بیشتر از طریق مکانیزم Interprocess Communication (XPC)، Universal Links و پردازش URL Scheme رخ می‌دهد. اپلیکیشنی که داده‌ها را از منابع خارجی بدون بررسی دریافت می‌کند، در برابر تزریق آسیب‌پذیر می‌شود. طبق Apple Security Research (2025)، حدود 12٪ از آسیب‌پذیری‌های اپلیکیشن‌های iOS به پاکسازی ناکافی داده‌های ورودی مرتبط است.

بردار مشترک برای هر دو پلتفرم — حمله از طریق ذخیره‌سازی محلی (SQLite، Realm، UserDefaults). اگر یک اپلیکیشن مخرب بتواند داده‌هایی را در دایرکتوری مشترک بنویسد، می‌تواند کدی تزریق کند که توسط اپلیکیشن هدف در هنگام خواندن اجرا شود.

فرآیند یک حمله معمولی شامل سه مرحله است: شناسایی — تحلیل نقاط ورودی اپلیکیشن (فرم‌ها، deep link‌ها، فایل‌ها)، تزریق — ارسال بار مخرب از طریق نقطه ورودی یافت‌شده، و بهره‌برداری — اجرای تزریق با دسترسی به داده‌ها یا عملکرد. درک این چرخه به توسعه‌دهنده کمک می‌کند در هر مرحله محافظت طراحی کند.

نمونه کد: پیاده‌سازی‌های آسیب‌پذیر و امن

بیایید نمونه‌های مشخص تزریق کد را در Kotlin برای Android و Swift برای iOS بررسی کنیم. هر نمونه الگوی آسیب‌پذیر و جایگزین امن آن را نشان می‌دهد.

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))
}

محافظت XSS در WebView: Swift برای iOS

نمونه دوم بارگذاری نادرست و صحیح محتوای HTML کاربر در WKWebView را نشان می‌دهد. استفاده از 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: محافظت در برابر حملات shell در Kotlin

سومین نمونه — خطر فراخوانی Runtime.exec() با آرگومان‌های کاربر و جایگزین امن از طریق کتابخانه با API ثابت.

// آسیب‌پذیر: دستور shell با ورودی کاربر
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()
}

روش‌های محافظت از اپلیکیشن‌های موبایل در برابر تزریق

محافظت در برابر تزریق کد نیازمند رویکردی سیستماتیک است که کد، زیرساخت و فرآیندهای توسعه را پوشش می‌دهد. هیچ روش واحدی امنیت کامل را تضمین نمی‌کند — ترکیبی از روش‌ها ضروری است.

سطح اول — پیشگیری: اعتبارسنجی دقیق تمام داده‌های ورودی. هر فیلدی که اپلیکیشن از کاربر، اپلیکیشن دیگر یا شبکه دریافت می‌کند باید از نظر نوع، طول و قالب بررسی شود. کتابخانه‌هایی مانند OWASP ESAPI اعتبارسنج‌های آماده برای سناریوهای رایج ارائه می‌دهند.

سطح دوم — پاکسازی و escape کردن: تبدیل داده‌ها قبل از استفاده در پرس و جوهای SQL، قالب‌های HTML یا دستورات shell. پرس و جوهای پارامتری SQL Injection را کاملاً حذف می‌کنند و escape کردن HTML مانع XSS می‌شود. در Android برای کار با SQLite از Room — ORM که به طور خودکار پارامترهای bind را اعمال می‌کند — استفاده کنید.

سطح سوم — حداقل‌سازی مجوزها: اپلیکیشن باید با حداقل حقوق لازم کار کند. از اصل کمترین دسترسی برای پایگاه داده، سیستم فایل و ارتباطات بین‌فرآیندی استفاده کنید. iOS این اصل را از طریق sandbox اپلیکیشن‌ها و Android را از طریق مدل مجوزها و جداسازی فرآیندها پیاده‌سازی می‌کند.

سطح چهارم — نظارت و واکنش: ثبت عملیات مشکوک، تشخیص ناهنجاری‌ها و مسدودسازی خودکار هنگام تکرار حملات. ابزارهایی مانند Firebase App Check به تشخیص درخواست‌های جعلی به بک‌اند از کلاینت‌های به خطر افتاده کمک می‌کنند. یکپارچه‌سازی RASP (Runtime Application Self-Protection) امکان مسدودسازی تزریق‌ها در زمان اجرا را فراهم می‌کند.

طبق تحقیقات Google Project Zero (2025)، ترکیب این چهار سطح خطر حمله موفق از طریق تزریق کد را 94٪ کاهش می‌دهد. به توسعه‌دهندگان توصیه می‌شود مکانیسم‌های محافظتی را در مرحله طراحی معماری پیاده‌سازی کنند، نه پس از کشف آسیب‌پذیری.