اختبار الحقن

لماذا يهم

بقي الحقن سنواتٍ ضمن قائمة OWASP Top 10 لأبرز مخاطر أمان تطبيقات الويب، لأن الوقوع في الخطأ سهل وعواقبه وخيمة: فاستعلام واحد لا يستخدم المعاملات قد يكشف كل صفوف جدول، أو يسمح بتجاوز تسجيل الدخول، أو يُفسد البيانات. والعيب غير مرئي في الاستخدام العادي — إذ تعمل الميزة تماماً مع المدخلات المعتادة — فيبقى حتى يرسل أحدهم مدخلاً لم يتوقعه المطوّر.

وبالنسبة إلى المختبِر، الحقن عمل عالي القيمة. فالفحوص زهيدة الكلفة، وتتبع نمطاً قابلاً للتكرار عبر كل مدخل يصل إلى مفسّر، والنتيجة المؤكَّدة تُصلَح سريعاً في الغالب لأن العلاج معروف جيداً. والعثور على موضع حقن واحد قبل الإصدار أرخص بكثير من اختراق في بيئة الإنتاج.

أين يحدث الحقن

لكل حقن الشكل نفسه: تُدمَج بيانات المستخدم مع أمرٍ لمفسّر ما، ولا يستطيع المفسّر أن يميّز أي جزء كان المقصود به أن يكون بيانات. وحيثما يبني التطبيق أمراً من نص يوجد موضع محتمل — ولا يلزم أن يكون المفسّر قاعدة بيانات.

• حقن SQL: يصل المدخل إلى استعلام قاعدة بيانات. وعلامة الاقتباس المفردة ' رمز خاص (Metacharacter)، أي حرف له معنى خاص لدى المفسّر، وهو هنا نهاية القيمة النصية؛ وغالباً ما تُثير خطأ قاعدة بيانات، وهو أول إشارة إلى أن المدخل يُحلَّل بوصفه SQL.
• حقن أوامر نظام التشغيل: يصل المدخل إلى أمر صدفة (Shell)، مثل اسم ملف يُدرجه التطبيق في أمر يشغّله. ويمكن لرموز الصدفة الخاصة مثل ; و| و& أن تغيّر ما يُنفَّذ.
• حقن LDAP وXPath وNoSQL: يصل المدخل إلى مرشّح دليل أو استعلام XML أو استعلام قاعدة بيانات مستندية، ولكلٍّ صياغته ورموزه الخاصة.
• حقن القوالب في جانب الخادم (Server-side template injection): يصل المدخل إلى محرّك قوالب يُقيّم التعابير، فقد يتحوّل اسمٌ في الملف الشخصي إلى شيفرة تُنفَّذ.
• الوصول أهم من اسم الحقل: فقيمة من رابط أو ترويسة أو ملف تعريف ارتباط أو ملف مرفوع قد تنتقل إلى مفسّر تماماً كما ينتقل حقل نموذج.

جرّبها: مولّد سيناريوهات الاختبار

الاختبار بأمان

اختبر فقط الأنظمة التي تملكها أو لديك إذن مكتوب باختبارها، وفضّل أخفّ مدخل يجيب عن السؤال. فالهدف معرفة ما إذا كان المدخل يُحلَّل بوصفه شيفرة، لا إحداث ضرر، لذا لا تستخدم أبداً حمولات (Payloads) تحذف البيانات أو تغيّرها أو تقرؤها.

وأكثر الفحوص الأولية أماناً رمزٌ خاص واحد بمفرده. فإذا أنتجت ' خطأ قاعدة بيانات أو تتبّع مكدّس (Stack trace) أو نتيجة متغيّرة بينما لا تفعل ذلك قيمة عادية، فالمدخل يصل إلى المفسّر دون حماية — وهذا يكفي لتسجيل عيب. ثم تؤكّد ذلك بمقارنة واحدة غير ضارة ولا تتجاوزها: علامتا اقتباس ''، وهما في SQL علامة اقتباس حرفية واحدة داخل القيمة النصية، ينبغي أن تُخفيا الخطأ؛ أو قيمة عادية يُضاف إليها بـAND شرط صحيح دائماً فتُعيد النتيجة المعتادة، بينما تُعيد القيمة نفسها مع شرط خاطئ دائماً لا شيء.

• استخدم الرموز الخاصة إشاراتٍ: ' و" و; و-- لـSQL؛ و; و| و& للصدفات؛ و* و( و) لـLDAP.
• راقب الفرق: خطأ قاعدة بيانات أو استجابة متغيّرة أو تأخّر أطول أو عدد صفوف مختلف بين مدخل عادي وآخر مُعَدّ خصيصاً هو الدليل.
• اختبر كل قناة، بما في ذلك المدخلات التي تخفيها الواجهة، لأن التحقق على الشاشة لا يحمي الخادم.
• لا تُشغّل أبداً سلاسل استغلال مُدمِّرة أو قارئة للبيانات؛ توقّف عند إثبات أن المدخل يُفسَّر.

جرّبها: مولّد مجموعات الأحرف الخاصة جرّبها: مولّد الاختبارات السلبية

مثال تطبيقي: الحل هو الاستعلامات ذات المعاملات

تأمّل بحثاً عن عميل يجد المستخدمين بالبريد الإلكتروني. النسخة القابلة للحقن تبني الاستعلام بدمج النصوص، فيقع المدخل داخل نص SQL. والحل استعلام ذو معاملات (Parameterised query)، ويُسمّى أيضاً عبارة مُعدّة مسبقاً (Prepared statement): يكون نص الاستعلام ثابتاً ويُرسَل المدخل إلى قاعدة البيانات منفصلاً، كقيمة لا يمكنها أبداً تغيير بنية الاستعلام.

والتحقق من المدخلات وتهريبها (Escaping) يساعدان، لكنهما ليسا الحل للحقن: فالحل هو سطر SQL في جدول سياقات الإخراج في الدرس السابق، أي الاستعلام ذو المعاملات. فالبيانات الصالحة تحتوي رموزاً خاصة بحق: فاسم العائلة O'Brien فيه فاصلة عليا، فلا يستطيع التحقق رفضها. أما تهريب هذه الرموز فليس إلا ملاذاً أخيراً في المفسّرات التي يتناولها هذا الدرس في جانب الخادم: فلكل مفسّر رموزه الخاصة، ورمز واحد يُغفَل يعيد فتح الثغرة. وفصل البيانات عن الشيفرة بتمرير القيم معاملاتٍ (Parameterisation) هو ما يغلقها فعلاً. أما الجزء من الاستعلام الذي لا يمكن ربطه معاملاً، كاسم عمود يُختار للترتيب، فيجب التحقق منه مقابل قائمة سماح ثابتة من الأسماء؛ وحسابات قاعدة البيانات ذات أقل الصلاحيات تحدّ من الضرر إن فات موضع حقن.

-- Vulnerable: input is pasted into the SQL text, so it can act as code
sql = "SELECT * FROM users WHERE email = '" + input + "'"

  input = ben@shop.test   ->  ... WHERE email = 'ben@shop.test'
  input = ' OR '1'='1     ->  ... WHERE email = '' OR '1'='1'   (logic changed)

-- Safe: the query text is fixed; input is bound as a separate value
sql    = "SELECT * FROM users WHERE email = ?"
params = [ input ]

  input = ' OR '1'='1     ->  compared as text; matches no row

جرّبها: مدقّق استعلامات SQL

ماذا تُبلّغ

يتيح تقرير الحقن الجيد للمطوّر أن يعيد إنتاج العيب ويصلحه دون تخمين. اذكر نقطة النهاية والمعامل بالضبط، والمدخل الذي أرسلته، والاستجابة التي تُثبت أن المدخل فُسِّر، والاستجابة لمدخل عادي بوصفها مرجعاً للمقارنة (Control). وبيّن الأثر من حيث ما يتحكم فيه المفسّر، وأوصِ بالحل.

• الموضع: الرابط أو الشاشة، وطريقة HTTP، والمعامل أو الحقل أو الترويسة أو ملف تعريف الارتباط بالضبط.
• المدخل والدليل: الأحرف التي أرسلتها بدقة والنتيجة المرصودة — نص الخطأ أو السلوك المختلف أو رمز الحالة — مع مدخل عادي بجانبه للمقارنة.
• الأثر والخطورة: ما يتحكم فيه المفسّر المتأثر (المصادقة، جدول بيانات، صدفة)، مع تقييم على مقياس الخطورة لدى فريقك.
• الحل: استعلامات ذات معاملات أو واجهة المفسّر الآمنة، مع التحقق وأقل الصلاحيات دفاعاً في العمق.
• النطاق: أشِر إلى أنك اختبرت النظام المصرَّح به فقط وتوقفت عند الإثبات، ليعرف القارئ أنه لم تُمَسّ أي بيانات.

جرّبها: منشئ طلبات API

أسئلة شائعة

المراجع

• OWASP Top 10:2025OWASP Foundation · 2025أخطر عشرة مخاطر أمنية لتطبيقات الويب، مع كيفية اختبار كل منها والوقاية منه.
• OWASP Web Security Testing Guide (WSTG)OWASP Foundationالمنهجية المرجعية لاختبار تطبيقات الويب وواجهات API بحثاً عن نقاط الضعف الأمنية، اختباراً تلو الآخر.
• OWASP Cheat Sheet Series: SQL Injection PreventionOWASP Foundationالاستعلامات ذات المعاملات، والإجراءات المخزنة المستخدمة بأمان، والتحقق بقائمة السماح، وأقل الصلاحيات — الدفاعات التي ينبغي أن يؤكدها اختبار قاعدة البيانات.
• OWASP Cheat Sheet Series: Injection PreventionOWASP Foundationمنع حقن SQL وأوامر النظام وغيرها عبر التعامل بالمعاملات والتحقق والتهريب.