SQL Injection في تطبيقات الموبايل: شرح وإصلاح

خطوة بخطوة في عالم Bug Hunting لتطبيقات الموبايل 📱🔍
هنفهم إزاي الثغرات بتحصل، وإزاي نكتشفها بشكل مسؤول، والأهم: إزاي نصلّحها صح عشان نحمي بيانات الناس 👮‍♂️🛡️
الثغرة: SQL Injection 💉

💉 يعني إيه SQL Injection ببساطة؟​

تخيل إن التطبيق عنده خانة بتكتب فيها اسم مستخدم أو منتج… الطبيعي إن السيرفر يعمل بحث عادي ويرجعلك النتيجة.
لكن لو التطبيق/السيرفر بيكوّن استعلام SQL بطريقة غلط، ممكن مدخلات المستخدم تتحول من “بيانات” إلى “جزء من الاستعلام” 😬
وساعتها بدل ما تطلب نتيجة واحدة… يحصل وصول لبيانات أكتر من المفروض 🚨

الشرح بالمثال البسيط:
كأنك بتكلم موظف استقبال وبتقوله “هات ملف أحمد”، لكن بسبب خطأ في النظام… يروح فاتحلك كل الملفات بدل ملف واحد 📂😱

---

🧾 تعريف رسمي وتصنيف الخطورة​

حسب تصنيف MITRE CWE، ثغرة SQL Injection لها رقم رسمي:

• CWE-89: SQL Injection
• وغالبًا بتتصنف حرجة جدًا (Critical) لأنها ممكن تسبب تسريب بيانات أو سيطرة على الحسابات حسب السيناريو 🔥

---

🧠 إزاي الثغرة دي بتحصل تقنيًا؟​

المشكلة غالبًا بتكون في بناء الاستعلامات بشكل “تركيب نص” بدل ما تكون “مُعلّمة/مُمرّرة كقيمة” ✅
مثال توضيحي (فكرة عامة):

SELECT * FROM users WHERE username = 'INPUT'

لو INPUT اتعامل معاه غلط، ممكن يحصل “تلخبط” في الاستعلام نفسه، وساعتها النتائج تبقى مش اللي متوقعينها.

مهم: الأمثلة هنا للتوضيح والتوعية فقط، من غير تفاصيل استغلال عملية أو سلاسل جاهزة.

🕵️‍♂️ إشارات بتساعدك تلاحظ SQL Injection بشكل مسؤول​

وأنت بتختبر تطبيق موبايل (أندرويد أو iOS)، في مؤشرات “بتلمّح” إن فيه مشكلة:

• ظهور رسائل أخطاء من نوع SQL syntax error أو database error في الردود 🧨
• تغيّر كبير في النتائج لما تدخل رموز غير متوقعة (زي علامات اقتباس أو رموز خاصة)
• Endpoint بحث/فلترة بيرجع نتائج “كتير زيادة” بشكل غير منطقي 🤨

ولو بتستخدم Proxy زي Burp Suite، تقدر تراقب الطلبات والاستجابات وتفهم الفلو بتاع الـ API بسهولة 👀

---

⚠️ ليه SQL Injection خطيرة فعلًا؟​

لو الثغرة موجودة في مكان حساس، النتائج ممكن تبقى كارثية:

1. تسريب بيانات المستخدمين (Data Breach) 📤
   أسماء، إيميلات، أرقام، بيانات حساسة… حسب اللي متخزن.
2. انتحال الهوية (Identity Theft) 🕵️
   لو تم الوصول لبيانات دخول أو Tokens أو Sessions.
3. تجاوز تسجيل الدخول (Authentication Bypass) 🔓
   في سيناريوهات معينة ممكن يحصل دخول بدون صلاحية كاملة.
4. تعديل/حذف بيانات (Data Manipulation) 🧯
   مش قراءة بس… ممكن تأثير مباشر على الداتا.
5. مخاطر أكبر على السيرفر 💣
   أحيانًا الأخطاء المركّبة (مع Misconfigurations) تفتح أبواب أخطر… عشان كده لازم تتقفل بسرعة.

---

🛠️ الإصلاح الصح (Remediation) - أهم جزء ✅​

1) استخدم Parameterized Queries (أقوى حل)​

بدل ما “تركّب” SQL بالنص… مرّر القيم كـ Parameters.
Python (SQLite / DB-API مثال):

cursor.execute("SELECT * FROM users WHERE name = ?", (user_input,))

Node.js (مثال عام بفكرة Prepared Statements):

const result = await db.query(
  "SELECT * FROM users WHERE name = ?",
  [userInput]
);

PHP (PDO):

$stmt = $pdo->prepare("SELECT * FROM users WHERE name = :name");
$stmt->execute(['name' => $userInput]);

2) Input Validation (فلترة منطقية)​

لو الحقل “اسم” مثلًا، يبقى لازم تقبل حروف معينة وتمنع أي حاجة غريبة ✋

3) Sanitization بحذر (مش بديل عن الـ Parameters)​

تنضيف المدخلات لوحده مش كفاية… لكن ممكن يساعد كطبقة إضافية 🧼

4) Least Privilege على حساب قاعدة البيانات​

حساب قاعدة البيانات الخاص بالتطبيق لازم يبقى بصلاحيات محدودة جدًا 👮‍♂️
مش محتاج DROP/ALTER في أغلب الحالات.

5) اختبارات أمنية مستمرة​

اختبر مع كل Release وراقب الـ Logs وخلي فيه مراجعة للكود وAPI Security Testing بشكل دوري 🔁

---

🎯 نصيحة سريعة للمبتدئين​

الباج هانتنج مش “اختراق وخلاص” 😄
ده محتاج:

• فهم التطبيق وBusiness Logic 🧠
• ملاحظة التفاصيل في الـ API والـ Mobile Flow 🔍
• أخلاق ومسؤولية في التعامل مع بيانات الناس ❤️
• تعاون مع الشركات عشان الإصلاح السريع 🤝

الباحث الأمني الحقيقي بيكتشف عشان يحمي… مش عشان يضر. ✅