حقن الكود في التطبيقات المحمولة — ما هو، أنواع الهجمات والحماية

ما هو حقن الكود؟

حقن الكود هو فئة من الهجمات حيث يقوم المهاجم بحقن كود قابل للتنفيذ في التطبيق من خلال بيانات إدخال غير موثوقة. في التطبيقات المحمولة، يكون الهجوم ممكنًا عبر حقول الإدخال والروابط العميقة والإشعارات الفورية ورموز QR وتبادل الملفات.

على عكس الهجمات على مستوى نظام التشغيل، يستغل حقن الكود أخطاء منطقية في كود التطبيق نفسه: عدم وجود escape، أو تسلسل سلاسل غير آمن، أو الثقة في مصادر البيانات الخارجية. وفقًا لتقرير Positive Technologies (2025)، تشكل الحقن 23% من جميع الثغرات الأمنية في التطبيقات المحمولة في القطاع المالي.

الخطر الرئيسي لحقن الكود هو الاختراق الكامل للبيانات: يمكن للمهاجم الوصول إلى قاعدة البيانات أو نظام ملفات الجهاز أو حسابات المستخدمين الآخرين. بالنسبة للتطبيقات المحمولة التي تتعامل مع بيانات الدفع أو المعلومات الطبية، يمكن أن تكون العواقب حرجة.

يحتاج المطورون إلى فهم أنواع الحقن وتطبيق آليات الحماية على جميع المستويات — من إدخال البيانات إلى عرضها وتخزينها. توفر الأطر الحديثة أدوات أمان مدمجة، لكن استخدامها يتطلب نهجًا واعيًا.

الأنواع الرئيسية لحقن الكود في التطبيقات المحمولة

يتضمن تصنيف حقن الكود ثلاثة أنواع رئيسية من الهجمات في سياق التطوير المحمول. يستغل كل نوع مكونات مختلفة من التطبيق ويتطلب طرق حماية محددة.

حقن SQL في التطبيقات المحمولة

حقن SQL (SQLi) هو حقن كود SQL ضار عبر معلمات الاستعلام إلى قاعدة بيانات محلية أو بعيدة. في التطبيقات المحمولة، تنشأ الثغرة عند العمل بشكل غير آمن مع SQLite على الجهاز أو عند بناء طلبات HTTP إلى REST API مع تسلسل السلاسل.

ناقل الهجوم النموذجي هو حقل بحث أو تصفية يتم إدخال قيمته مباشرة في استعلام SQL. إذا استخدم المطور التسلسل المباشر بدلاً من الاستعلامات المعلمة، يمكن للمهاجم تمرير سلسلة مثل 1' OR '1'='1. وفقًا OWASP Mobile Top 10 (2024)، يظل حقن SQL ثاني أكثر الثغرات الأمنية الحرجة شيوعًا في التطبيقات المحمولة في فئة تخزين البيانات غير الآمن.

تعتمد الحماية من SQLi على ثلاثة مستويات: استخدام الاستعلامات المعلمة (PreparedStatement في Java، rawQuery مع bindArgs في Android)، والتحقق من صحة الإدخال على جانب العميل والخادم، والحد الأدنى من صلاحيات قاعدة البيانات.

البرمجة النصية عبر المواقع (XSS) في WebView

تهاجم هجمات XSS في التطبيقات المحمولة مكون WebView — متصفح مدمج يعرض محتوى HTML. إذا قام التطبيق بتحميل بيانات من مصادر خارجية إلى WebView دون تنقية، يمكن للمهاجم حقن كود JavaScript يتم تنفيذه في سياق التطبيق.

هناك نوعان فرعيان من XSS: XSS المخزن — يتم حفظ النص الضار على الخادم وتنفيذه في كل مرة يتم فيها عرض الصفحة، و XSS المنعكس — يتم تمرير الكود عبر URL أو معلمات POST ويتم تنفيذه مرة واحدة. في التطبيقات المحمولة، يعتبر XSS المخزن عبر التعليقات أو المراجعات أو محتوى المستخدم المعروض في WebView لمستخدمين آخرين خطيرًا بشكل خاص.

تتضمن الحماية تعطيل JavaScript في WebView إذا لم يكن مطلوبًا، واستخدام سياسة أمان المحتوى (CSP)، وتنقية محتوى HTML عبر مكتبات مثل Jsoup لنظام Android أو SwiftSoup لنظام iOS.

حقن الأوامر عبر Intent و Shell

حقن الأوامر هو تنفيذ أوامر النظام على الجهاز عبر استدعاءات غير منقية لـ Runtime.exec() أو ProcessBuilder أو NSTask. في التطبيقات المحمولة، يكون الهجوم ممكنًا إذا قام التطبيق بتمرير بيانات المستخدم إلى أوامر شل أو Intents مع إجراءات.

المناطق الأكثر عرضة للخطر هي وظائف تحويل الملفات ومعالجة الوسائط (ffmpeg، ImageMagick) وتثبيت المكتبات الخارجية. يمكن للمهاجم تمرير أمر برمز أنبوب أو إعادة توجيه ينفذ كودًا عشوائيًا على الجهاز. Android يقيد جزئيًا الوصول إلى شل عبر sandbox، لكن التطبيقات ذات الوصول الجذر أو استغلالات PrivEsc يمكن اختراقها.

الحماية الموصى بها هي الرفض الكامل لـ Runtime.exec() لمعالجة بيانات المستخدم، واستخدام المكتبات بواجهة برمجة تطبيقات آمنة، والعزل الصارم للعمليات الخارجية.

كيف يعمل حقن الكود على Android و iOS

تختلف آلية حقن الكود على منصتي Android و iOS بسبب الاختلافات المعمارية. على Android، ترتبط الحقن غالبًا بـ Intent — رسالة نظام يتم تمريرها بين مكونات التطبيق. يمكن للمهاجم إرسال Intent ضار ببيانات إضافية تحتوي على كود SQL أو أوامر شل.

على iOS، تحدث الهجمات غالبًا عبر آلية الاتصال بين العمليات (XPC) والروابط الشاملة ومعالجة URL Scheme. يصبح التطبيق الذي يقبل بيانات من مصادر خارجية دون تحقق عرضة للحقن. وفقًا Apple Security Research (2025)، حوالي 12% من الثغرات الأمنية في تطبيقات iOS مرتبطة بعدم كفاية تنقية بيانات الإدخال.

ناقل مشترك لكلا المنصتين هو الهجوم عبر التخزين المحلي (SQLite، Realm، UserDefaults). إذا تمكن تطبيق ضار من كتابة بيانات إلى دليل مشترك، يمكنه حقن كود سيتم تنفيذه بواسطة التطبيق المستهدف عند القراءة.

تتضمن عملية الهجوم النموذجية ثلاث مراحل: الاستطلاع — تحليل نقاط دخول التطبيق (النماذج، الروابط العميقة، الملفات)، الحقن — تسليم الحمولة الضارة عبر نقطة الدخول التي تم العثور عليها، والاستغلال — تنفيذ الحقن للحصول على الوصول إلى البيانات أو الوظائف. يساعد فهم هذه الدورة المطورين على تصميم الحماية في كل مرحلة.

أمثلة كود: تطبيقات ضعيفة وآمنة

دعنا نلقي نظرة على أمثلة محددة لـ حقن الكود في Kotlin لنظام Android و Swift لنظام iOS. يظهر كل مثال نمطًا ضعيفًا وبديله الآمن.

حقن SQL: كود ضعيف في 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)

حقن الأوامر: الحماية من هجمات شل في Kotlin

المثال الثالث هو خطر استدعاء Runtime.exec() مع وسائط المستخدم وبديل آمن عبر مكتبة بواجهة برمجة تطبيقات ثابتة.

// ضعيف: أمر شل مع إدخال المستخدم
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 أو أوامر شل. تقضي الاستعلامات المعلمة تمامًا على حقن SQL، ويمنع HTML escape هجمات XSS. على Android، استخدم Room للعمل مع SQLite — ORM يطبق تلقائيًا معلمات bind.

المستوى الثالث هو تقليل الصلاحيات: يجب أن يعمل التطبيق بالحد الأدنى من الأذونات الضرورية. استخدم مبدأ أقل صلاحية لقاعدة البيانات ونظام الملفات والتواصل بين العمليات. iOS يطبق هذا المبدأ من خلال sandbox، و Android من خلال نموذج الأذونات وعزل العمليات.

المستوى الرابع هو المراقبة والاستجابة: تسجيل العمليات المشبوهة واكتشاف الحالات الشاذة والحظر التلقائي عند تكرار الهجمات. تساعد أدوات مثل Firebase App Check في اكتشاف الطلبات المزيفة إلى الخادم الخلفي من العملاء المخترقين. يتيح تكامل RASP (الحماية الذاتية للتطبيق في وقت التشغيل) حظر الحقن في وقت التشغيل.

وفقًا لدراسة Google Project Zero (2025)، يقلل الجمع بين هذه المستويات الأربعة من خطر هجوم ناجح عبر حقن الكود بنسبة 94%. يوصى للمطورين بتنفيذ آليات الحماية في مرحلة تصميم البنية، بدلاً من إضافتها بعد اكتشاف الثغرات الأمنية.