حقن SQL: أنواعه، مخاطره، وطرق الحماية العملية

إيه هو SQL Injection ؟ ​

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

ليه الخطر ده حقيقي؟ ​

الـSQL Injection ممكن يوصلك لتسريب بيانات حساسة، تغيير قواعد البيانات، تعطيل الخدمة، أو في بعض الحالات لو السيستم مُهيأ غلط ممكن يوصل لملفات السيرفر أو تنفيذ أوامر. المشاكل دي بتأثر على السمعة، المستخدمين، وشركتك.

أسباب وجود ثغرة SQL Injection (ببساطة) ​

• عرض رسائل خطأ مفصّلة بتكشف جداول/أسماء أعمدة.
• كشف نسخة الـDBMS (banner) اللى بتسهّل بحث عن ثغرات معروفة.
• اختلاف لهجات SQL بيدي مؤشر لنوع القاعدة.
• فلترة غير كفاية على المدخلات أو اعتماد كامل على الـclient-side validation.

أنماط SQL Injection بإيجاز ​

• Error-Based: المهاجم يستفيد من رسائل الخطأ عشان يعرف بنية القاعدة.
• UNION-Based: بدمج نتايج استعلامات للحصول على بيانات إضافية.
• Inferential / Blind: مفيش داتا بترجع مباشرة؛ المهاجم بيستنتج عن طريق تغيّر الاستجابة (بياخد وقت).
• Boolean-Based: يسأل أسئلة بنعم/لا ويقارن الاستجابات.
• Time-Based: يعتمد على تأخير الاستجابة لمعرفة صحة شرط معين.

أمثلة كود (آمنة، تعليمية) - إعرف الفرق بين الكود الضعيف والآمن ​

مثال غير آمن (ما تستخدموش): استعمال تركيب استعلام بضم مدخلات المستخدم مباشرة

# مثال عام توضيحي (لغة شبه-Python/ pseudocode)
user_id = request.GET['id']
sql = "SELECT * FROM users WHERE id = " + user_id
cursor.execute(sql)

العيب هنا إن أي حاجة المستخدم يكتبها هتتضاف جوا الاستعلام، وده بيفتح باب الحقن.

المقابل الآمن (Prepared Statements / Parameterized):

# نفس المثال بطريقة آمنة باستخدام Prepared Statements
user_id = request.GET['id']
sql = "SELECT * FROM users WHERE id = ?"
cursor.execute(sql, (user_id,))

هنا القيمة بتتبعت كـ parameter منفصل عن هيكل الاستعلام، فمش هتتفهم كجزء من الـSQL.

إزاي تكتشف وجود ثغرة بشكل عملي؟ ​

• راقب اللوجات على محاولات إدخال رموز غريبة أو تكرار في الباراميترات.
• اعمل فحص آلى (SAST/DAST) بانتظام.
• راجع كل النهايات (endpoints) اللي بتستقبل مدخلات من المستخدم - مش بس الفورمز، كمان رؤوس الـHTTP والكوكيز والـAPI.
• شغّل تحذيرات على استعلامات غير معتادة أو وقت استجابة طويل.

ازاي تحمي النظام خطوة بخطوة؟ ​

• استخدم Prepared Statements في كل استعلام بيتعامل مع مدخلات يوزر.
• طبق Input Validation بالـwhitelist (لو المفروض رقم يبقى رقم).
• ما تعرضش رسائل خطأ تقنية للمستخدم؛ خلي التفاصيل في اللوج بس.
• مبدأ أقل صلاحية (Least Privilege): كل حساب DB ياخد أقل صلاحيات لازمة.
• فعّل WAF وراقب الtraffic الغريب.
• حدّث الـDBMS والفريموركس بانتظام.

شوية خرافات نحب نفكّها ​

• مش بتموت الموضوع علشان قديم - SQLi لسه سبب ل breaches كبيرة.
• إلغاء الفورمز مش معناه أمان كامل. المدخلات ممكن تيجي من مصادر تانية.
• تقليل صلاحيات مفيد لكن مش كفاية لو فيه استعلامات تهاجم أداء النظام.

خطوات سريعة للفريق (Checklist) ​

• راجع كل استعلام بيستقبل مدخلات يوزر.
• طبّق Prepared Statements في كل مكان.
• شغّل logging وalerting على نماذج استعلامات غريبة.
• اعمل مراجعات أمنية دورية ودرّب الفريق على secure coding.

لو عايز تحمي موقعك: افحص، فلتر، جهّز. استبدال الاستعلامات الضعيفة بـPrepared Statements واتباع مبدأ أقل صلاحية مع مراقبة مستمرة هيوفروا لك دفاع قوي ضد SQL Injection.