ثغرة SQL Injection: شرح الحماية والطريقة بسهولة

ثغرة SQL Injection: إيه هي وليه مهمة؟ ​

ثغرة SQL Injection هي نوع من ثغرات الحقن اللي بتحصل لما التطبيق يدي مساحة لمدخلات المستخدم تتعامل كجزء من استعلام قاعدة البيانات من غير فلترة أو تحقّق كويس. النتيجة إن مهاجم ممكن يغيّر نية الاستعلام ويسيء استخدامه للوصول لبيانات مش مفروض يوصلها أو يعدّلها أو يمسحها.

الخطورة: دي واحدة من أقدم وأخطر الثغرات في تطبيقات الويب - منظمة OWASP بتصنّفها من أهم المخاطر لتطبيقات الويب لأن تأثيرها ممكن يكون كارثي على بيانات المستخدمين والسمعة.

إزاي بتحصل ثغرة SQL Injection؟ ​

المشكلة جوهرها إن الكود بيركب قيمة من المستخدم جوا استعلام SQL من غير ما يفرّق بين "نص" و"تعليمات". مثال مبسّط: لو ممكن إدخال المستخدم يدخل في الاستعلام زي كده:

sql = "SELECT * FROM users WHERE id = " + user_input;

فلو user_input مش متعقّم، ممكن يتحوّل لاستعلام مختلف عن اللي انت قصدته.

أضرار الثغرة وإيه اللي ممكن يحصل لو استُغلت ​

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

أكواد توضيحية: الفرق بين كود ضعيف وآمن (تعليمي) ​

مثال كود غير آمن (توضيحي - لا تستخدمه)​

// لا تستخدم هذا النمط في الإنتاج

$id = $_GET['id'];
$sql = "SELECT * FROM users WHERE id = $id";
$result = mysqli_query($conn, $sql);

النقطة: هنا قيمة $id بتدخل جوا الاستعلام مباشرة - وده بيخلّي الاستعلام عرضة للحقن.

مثال آمن باستخدام PDO وPrepared Statements (PHP) - نستخدمه دايمًا​

// استخدام PDO مع معاملات مُعَدّة (Parameterized Queries)
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
$stmt->execute(['id' => $_GET['id']]);
$user = $stmt->fetch();

الفائدة: قيمة الـid تُعامل كقيمة منفصلة عن هيكل الاستعلام - متتحوّلش لأمر SQL.

مثال آمن في Python (باستخدام parameterized queries)​

# مثال تعليمي باستخدام psycopg2 (Postgres)
cur.execute("SELECT * FROM users WHERE id = %s", (user_id,))
rows = cur.fetchall()

مبدأ واحد: افصل القيم عن الاستعلام.

أساليب الحماية الأساسية (للمطورين ومُديري الأنظمة) ​

• استخدم Prepared Statements / Parameterized Queries دايمًا.
• لو بتستخدم ORM (مثل SQLAlchemy, Doctrine, ActiveRecord) خليك على الطرق الآمنة الموصى بيها بدل كتابة استعلامات يدوية.
• فعّل Validation وwhitelisting للمدخلات (لو المفروض رقم يبقى رقم؛ لو معرّف محدد استقبل القيم المتوقعة فقط).
• قلّل صلاحيات حساب الداتابيز: مبدأ Least Privilege - الحساب اللي بيتصل للداتا بيز مايمسحش جداول لو مش لازم.
• أخفي رسائل الأخطاء التفصيلية عن المستخدمين وحطها بس في اللوجّز الخاصة بالإدارة.
• فعّل سجلات (logs) للاستعلامات الحساسة وراقبها بطريقة آلية لاكتشاف أنماط مش طبيعية.
• استخدم Web Application Firewall (WAF) كطبقة إضافية للحماية والمراقبة.

نصايح تشغيلية للكشف المبكر والاستجابة ​

• اعمل مسح دوري بالـ SAST/DAST (أدوات فحص الثغرات) على الكود والبيئة.
• راجع تغييرات الكود بعناية (code reviews) وضمّ أداة تحليل أمني ضمن CI/CD.
• حدّد خطة استجابة للحوادث: عمل snapshot، عزل النظام، استرجاع من النسخ الاحتياطية، وإبلاغ الجهات المعنية.

أخطاء شائعة لازم تتجنّبها ​

• الاعتماد فقط على فلترة جهة العميل (client-side). لازم تحقق على السيرفر.
• حفظ بيانات اتصال قوية في ملف الكود بدون تشفير أو متغيرات بيئية (Env).
• إعطاء حساب الداتابيز صلاحيات إدارية زائدة.
• عرض رسائل خطأ SQL للمستخدمين العاديين.

Checklist سريع للفريق - اعملها دلوقتي ​

• استبدال كل الاستعلامات المباشرة بـ Prepared Statements.
• مراجعة الصلاحيات على قاعدة البيانات (Least Privilege).
• تفعيل وتكوين سجلات الاستعلام ومتابعة التنبيهات.
• فحص الكود باستخدام أدوات SAST/DAST قبل النشر.
• إخفاء تفاصيل أخطاء قاعدة البيانات عن الواجهة العامة.
• وجود نسخ احتياطية وخطة استرداد عملانية.

الخلاصة - إيه اللي لازم تبدأ بيه النهارده؟ ​

لو لسة بتستخدم استعلامات مركّبة بتضم مدخلات يوزر مباشرة - خليك مركز: بدّلها لـ Prepared Statements فورًا، قلّل صلاحيات حسابات الداتا بيز، فعّل الـlogging وادمج فحص أمني ضمن خط التطوير (CI). الوقاية دي أرخص بكتير من تكلفة التعافي لو حصل اختراق.