طالما أن موقعك الإلكتروني أو تطبيقك المصغر أو تطبيقك يقدم خدمات للجمهور، فسيتم حتمًا فحصه واستكشافه ومهاجمته، والفرق الوحيد هو ما إذا كان قد تم اكتشاف ذلك أم لا. تركز العديد من الفرق كل طاقتها على تطوير الميزات وسرعة الإطلاق، ويؤجل اختبار الأمان مرارًا وتكرارًا، ونتيجة لذلك، يمكن لواجهة برمجية تتجاوز الصلاحيات أو نقطة رفع ملفات واحدة أن تُسقط النظام بأكمله. لقد رأت MIC Studio مرارًا وتكرارًا في خدمات اختبار الأمان والاختبار العكسي طويلة الأمد نفس النمط: ما يخترق النظام فعليًا غالبًا ليس تقنية بالغة التعقيد، بل عدة فئات من المشكلات القديمة المهملة. توضح هذه المقالة الثغرات الأكثر شيوعًا في اختبار أمان المواقع بعمق، وتقدم توصيات تحصين يمكن تنفيذها مباشرة.
أولًا: افهم أولًا أهداف وحدود اختبار الأمان
اختبار الأمان ليس شراء مجموعة من أدوات الفحص وتشغيلها ثم الانتهاء. إنه يجب أن يجيب على ثلاثة أسئلة: من أي مدخل يمكن للمهاجم الدخول؟ ما مقدار ما يمكنه الحصول عليه بعد الدخول؟ ما حجم الضرر الذي يمكنه إحداثه بعد الحصول عليه؟
حسب طريقة الاختبار، عادةً ما تكون هناك ثلاث فئات:
- الاختبار الصندوقي الأسود: محاكاة كاملة لمهاجم خارجي، دون امتلاك الكود المصدري أو الحسابات، وهو الأقرب إلى سيناريو الهجوم الحقيقي؛
- الاختبار الصندوقي الأبيض: يجمع بين تدقيق الكود المصدري، ويمكنه اكتشاف مشكلات منطقية عميقة لا يستطيع الاختبار الأسود اكتشافها؛
- الاختبار الصندوقي الرمادي: الحصول على بعض الحسابات أو وثائق الواجهات البرمجية، وهو الأعلى كفاءة، ومناسب للمشاريع ذات التكرار المتكرر.
بالنسبة لمعظم المشاريع الصغيرة والمتوسطة، فإن إعطاء الأولوية لاختبار طبقة الواجهات البرمجية وطبقة الصلاحيات هو الأعلى قيمة. لأن هاتين المنطقتين هما الأكثر تكرارًا في المشكلات، والعواقب فيهما هي الأشد — تسريب البيانات، والعمليات المتجاوزة للصلاحيات، والاستيلاء على لوحة التحكم، كلها تبدأ أساسًا من هنا.
ثانيًا: حقن SQL: مشكلة قديمة، لكنها لا تزال القاتل الأول
وُجد حقن SQL منذ أكثر من عشرين عامًا، لكنه حتى اليوم من الضيوف الدائمين في قوائم الثغرات المختلفة. السبب بسيط: طالما أن هناك موضعًا واحدًا لـ SQL تم تجميعه بدمج النصوص، فقد يكون قابلًا للاستغلال.
السيناريوهات النموذجية:
- واجهة تسجيل الدخول تستخدم دمج النصوص للاستعلام عن المستخدم، وإدخال `' or '1'='1` يتجاوز كلمة المرور مباشرة؛
- حقول الترتيب وشروط البحث في استعلامات القوائم تُدمج مباشرة في SQL، مما يؤدي إلى حقن بالأخطاء أو حقن أعمى زمني؛
- بعض الأنظمة القديمة تستخدم ORM لكنها تدمج SQL أصليًا، وهناك أيضًا مخاطر.
توصيات التحصين:
- استخدام الاستعلامات ذات المعاملات (العبارات المُجمّعة مسبقًا) بشكل شامل، ومنع دمج النصوص في SQL على مستوى معايير الكود؛
- المواضع التي لا يمكن تمرير معاملات فيها مثل حقول الترتيب وأسماء الجداول، تُتحقق بقائمة بيضاء، ويُسمح فقط بالقيم المحددة مسبقًا؛
- حساب قاعدة البيانات يتبع مبدأ الحد الأدنى من الصلاحيات، ولا يُمنح حساب الأعمال صلاحيات عالية الخطورة مثل DROP وFILE وGRANT؛
- إغلاق عرض الأخطاء التفصيلية في بيئة الإنتاج، لتجنب تسريب بنية الجداول وإصدار قاعدة البيانات؛
- إدخال WAF كخط دفاع تكميلي، لكن لا تعتبره الحماية الوحيدة.
ثالثًا: XSS البرمجة النصية عبر المواقع: الحقن الأطول潜伏ًا
جوهر XSS هو تنفيذ إدخال المستخدم ككود. XSS المخزّن هو الأخطر، لأنه يبقى في الصفحة لفترة طويلة ويؤثر على كل زائر.
السيناريوهات النموذجية:
- قسم التعليقات، والألقاب، والتوقيعات الشخصية تُخرج مباشرة إلى الصفحة؛
- محرر النصوص المنسقة يسمح بوسوم `