يعود ظهور هجمات SQL injection إلى أواخر التسعينيات، ولا تزال حتى اليوم من أكثر وسائل الهجوم استخدامًا ضد المواقع الإلكترونية. ليس ذلك لأنها حيلة ذكية جديدة، بل لأن الكثير من التطبيقات ما زالت تترك الباب مفتوحًا. ويُعد جدار حماية تطبيقات الويب من أكثر الأدوات فعالية لإغلاق هذا الباب قبل أن يصل المهاجم إلى قاعدة بياناتك من الأساس.
لنستعرض كيف تعمل هجمات SQL injection فعليًا، ولماذا هي خطيرة جدًا، وكيف يرصدها جدار حماية تطبيقات الويب بالضبط في حينها.
ما الذي يفعله SQL Injection حقًا
يحدث SQL injection عندما يُدخل المهاجم أوامر ضارة موجهة لقاعدة البيانات في حقل نموذج، أو معلمة رابط، أو طلب API. إذا لم يقم تطبيقك بتنقية هذا الإدخال بشكل صحيح، فإن الكود الضار يمرّ مباشرة إلى قاعدة بياناتك كما لو كان استعلامًا شرعيًا.
هذا مثال كلاسيكي. تخيّل نموذج تسجيل دخول يبني استعلامًا كهذا في الخلفية:
SELECT * FROM users WHERE username = 'input' AND password = 'input'
إذا كتب المهاجم ' OR '1'='1 في حقل اسم المستخدم بدلًا من اسم مستخدم حقيقي، يتحول الاستعلام إلى شيء يكون صحيحًا دائمًا. وحسب طريقة كتابة الكود، قد يسمح هذا له بتسجيل الدخول دون كلمة مرور، أو الأسوأ من ذلك، استخراج جدول المستخدمين بالكامل.
لماذا هي خطيرة جدًا
لا يقتصر SQL injection على كشف سجل واحد فقط. فالهجوم الناجح يمكن أن:
- يستخرج قواعد بيانات العملاء بالكامل، بما فيها كلمات المرور وتفاصيل الدفع
- يعدّل أو يحذف البيانات، بما في ذلك الأسعار أو الطلبات أو صلاحيات المستخدمين
- يمنح المهاجم صلاحيات إدارية على تطبيقك
- في بعض الحالات، يسمح للمهاجم بتنفيذ أوامر على الخادم الأساسي
يحتل SQL injection مكانة متقدمة في قائمة OWASP Top 10 لمخاطر أمان تطبيقات الويب لسبب واضح. فهو رخيص التنفيذ، وسهل الأتمتة، ومدمّر عند النجاح.
كيف يرصده جدار حماية تطبيقات الويب أولًا
يقف جدار حماية تطبيقات الويب بين الزيارات الواردة وتطبيقك، ويفحص كل طلب قبل أن يصل إلى الكود الخاص بك. تخيله كنقطة تفتيش تقرأ محتوى كل نموذج مُرسل، ورابط، وترويسة، بحثًا عن أنماط لا يجب أن تكون موجودة.
مطابقة الأنماط والتوقيعات
تتبع معظم محاولات SQL injection أنماطًا يمكن التعرف عليها، مثل علامات الاقتباس غير المتوقعة، أو ظهور كلمات مفتاحية خاصة بـ SQL مثل UNION أو SELECT أو DROP في مواضع غير مناسبة، أو استخدام صياغة التعليقات لقطع الاستعلام مبكرًا. يحتفظ جدار حماية تطبيقات الويب بمكتبة من هذه التوقيعات، ويقوم بوضع علامة على الطلبات المطابقة لها أو حظرها، غالبًا بالاستناد إلى مجموعات قواعد مثل تلك التي يحافظ عليها مشروع OWASP Core Rule Set.
التحقق من صحة الإدخال عند الحافة
بالإضافة إلى مطابقة سلاسل الهجوم المعروفة، يفرض جدار حماية تطبيقات الويب الجيد قواعد حول ما يجب أن يحتويه الحقل. فحقل رقم الهاتف مثلًا لا يجب أن يقبل علامات الاقتباس أو الفواصل المنقوطة. وعندما يرى الجدار إدخالًا يخالف الشكل المتوقع للطلب، يمكنه رفضه قبل حتى أن يبدأ منطق تطبيقك بالعمل.
الرصد السلوكي والمعتمد على معدل الطلبات
نادرًا ما يحصل المهاجمون على الصيغة الصحيحة للهجوم من أول محاولة. فهم يجربون مرارًا، ويختبرون تنويعات مختلفة إلى أن يتمكن أحدها من الاختراق. يمكن لجدار حماية تطبيقات الويب رصد هذا النمط من الطلبات المتكررة والمتغيرة قليلًا من نفس المصدر، وبدء حظر تلك الزيارات أو تحديها، حتى لو بدا كل طلب على حدة غير مؤكد الخطورة.
تحدثنا عن كيفية توسّع هذا النوع من رصد الأنماط إلى ما هو أبعد من SQL injection في شرح قواعد WAF: كيف يقرر جدار حماية تطبيقات الويب ما يجب حظره.
لماذا يهم هذا أكثر من إصلاح الكود وحده
يفترض بعض المطورين أن استخدام الاستعلامات المُعدّة مسبقًا (parameterized queries) أو ORM كافٍ لإيقاف SQL injection تمامًا. في عالم مثالي، سيكون ذلك صحيحًا. لكن التطبيقات الحقيقية معقدة، فيها كود قديم، وإضافات من جهات خارجية، ومقاولون كتبوا حلًا سريعًا منذ خمس سنوات لا يتذكره أحد. استعلام واحد غير مُنقّى ومدفون في مكان ما ضمن قاعدة كود ضخمة يكفي لحدوث الكارثة.
هنا يبرز دور جدار حماية تطبيقات الويب. فهو لا يتطلب منك إيجاد وإصلاح كل سطر كود ضعيف. بل يرصد الإدخال الضار عند الباب، بغض النظر عن كون الكود الذي يقف خلفه آمنًا أم لا. إنه طبقة دفاع ثانية لا تعتمد على أن يكون تطبيقك مثاليًا، وهو أمر، بصراحة، لا ينطبق على أي تطبيق.
مثال عملي
لنفترض أن موقعك يستخدم إضافة قديمة تحتوي على ثغرة معروفة في SQL injection ضمن ميزة بحث نادرة الاستخدام. قد لا تعرف حتى بوجودها. يجدها فاحص أوتوماتيكي في غضون ساعات من الإفصاح العام عنها. بدون جدار حماية تطبيقات الويب، تكون هذه الثغرة بابًا مفتوحًا. ومع وجوده، يتم رصد الاستعلام الضار وحظره قبل أن يصل إلى قاعدة بياناتك أبدًا، مما يمنحك وقتًا لإصلاح الكود الفعلي.
لنظرة أوسع على كيفية اندماج هذا مع منظومة أمانك الشاملة، راجع تهديدات OWASP Top 10 وكيف يتعامل جدار حماية تطبيقات الويب مع كل منها.
كيف تحصل على حماية صحيحة من SQL Injection
إذا كنت تقيّم دفاعاتك الحالية، إليك ما يجب البحث عنه:
- مجموعة قواعد يتم تحديثها بانتظام مع ظهور تقنيات هجوم جديدة
- سجلات تتيح لك رؤية ما تم حظره والتحقيق في الأنماط المشبوهة
- إمكانية ضبط القواعد بحيث لا يتم حظر الزيارات الشرعية خطأً
- تغطية شاملة لكل نقاط الإدخال، لا فقط نموذج تسجيل الدخول أو البحث الرئيسي
نحن نشغّل جدار حماية تطبيقات الويب أمام كل موقع نستضيفه، وضبطناه لرصد هذه الأنماط دون التأثير على الزوار الحقيقيين. إذا أردت معرفة كيفية عمل عملية التصفية بنفسها، اطّلع على نظرة عامة عن WAF لدينا.
خلاصة الأمر
يُعد SQL injection هجومًا قديمًا وموثّقًا جيدًا، ولا يزال فعّالًا بشكل مخيف ضد المواقع التي لم تغلق ثغراتها. ممارسات الكتابة الآمنة للكود مهمة، لكنها ليست ضمانًا كاملًا. يمنحك جدار حماية تطبيقات الويب طبقة حماية ترصد الإدخال الضار قبل أن يصل إلى قاعدة بياناتك، بغض النظر عن ما يختبئ في قاعدة كودك. اجمع ذلك مع تدقيق منتظم للكود وستحصل على دفاع لا يعتمد على أن يسير كل شيء بشكل مثالي.
