وصف إقحام SQL
يُعد إقحام SQL أحد أكثر الأساليب الشائعة المستخدمة لخرق البيانات. يتمثل جوهر الهجوم في أنه يتم إلحاق أمر SQL بنهاية خلفية لحقل النموذج على الواجهة الأمامية للتطبيق أو الويب (عادةً من خلال موقع ويب)، بهدف كسر برنامج SQL النصي الأصلي ثم تنفيذ برنامج SQL النصي الذي تم إقحامه في حقل النموذج. غالباً ما يحدث إقحام SQL هذا عندما تقوم بإنشاء SQL ديناميكياً داخل تطبيق العميل الخاص بك. يرجع السبب الأساسي وراء هجوم إقحام SQL إلى ممارسات الترميز غير الصالحة داخل تطبيق العميل وداخل الإجراءات المخزنة في قاعدة البيانات. لقد تعلم العديد من المطورين ممارسات تطوير أفضل، لكن إقحام SQL لا يزال يمثل مشكلة كبيرة بسبب عدد التطبيقات القديمة التي لا تزال قيد الاستخدام والتطبيقات الأحدث التي أنشأها المطورون الذين لم يفكروا في خطر إقحام SQL جدياً أثناء إنشاء التطبيق.
على سبيل المثال، لنفترض أن تطبيق الويب للواجهة الأمامية ينشئ عبارة SQL ديناميكية كما هو موضح أدناه:
SELECT * FROM Orders WHERE OrderId=25
يتم إنشاء T-SQL هذا عندما ينتقل المستخدم إلى جزء محفوظات أمر المبيعات في موقع الشركة الإلكتروني ويُدخل "25" في حقل النموذج لرقم معرف الأمر. ومع ذلك، لنفترض أن المستخدم أدخل أكثر من مجرد رقم المعرف، على سبيل المثال "25؛ DELETE FROM Orders؛"
في هذه الحالة، سيكون الاستعلام المرسل إلى قاعدة البيانات الخاصة بك كما هو موضح أدناه:
SELECT * FROM Orders WHERE OrderID=25; DELETE FROM Orders;
الطريقة التي يعمل بها الاستعلام في المثال أعلاه هي أن الفاصلة المنقوطة "؛" تخبر قاعدة بيانات SQL أن العبارة قد انتهت وأن هناك عبارة أخرى ينبغي تشغيلها. تقوم قاعدة البيانات بعد ذلك بمعالجة العبارة التالية وفقاً للتعليمات، مما يؤدي إلى حذف جميع الصفوف من جدول الأوامر.
يتم تشغيل استعلام SELECT الأولي كالمعتاد دون حدوث أي أخطاء. ومع ذلك، عندما تنظر إلى جدول الأوامر، لن ترى أي صفوف. إذ إنه تم تنفيذ الاستعلام الثاني في الدفعة، والذي يقوم بحذف جميع الصفوف.
تتمثل إحدى التقنيات المستخدمة لمنع هجمات إقحام SQL في فحص نص المعلمات، أو القيم التي تم إدخالها في حقول النموذج، بحثاً عن كلمات أساسية مختلفة. ومع ذلك، يوفر هذا الحل الحد الأدنى من الحماية فحسب، إذ توجد طرق عديدة لإجبار هذه الهجمات على العمل. تتضمن بعض تقنيات الإقحام هذه تمرير البيانات الثنائية، وجعل محرك قاعدة البيانات يقوم بتحويل البيانات الثنائية مرة أخرى إلى سلسلة نصية، ثم تنفيذ السلسلة بعد ذلك. يمكنك رؤية مثال بسيط على هذه المشكلة عن طريق تشغيل رمز T-SQL أدناه.
DECLARE @v VARCHAR(255)
SELECT @v = cast(0x73705F68656C706462 AS VARCHAR(255))
EXEC (@v)
عندما يقبل المستخدم البيانات، سواء أكان عميلاً أم موظفاً، فإن إحدى الطرق المفيدة لضمان عدم استخدام القيمة في هجوم إقحام SQL هي التحقق من أن البيانات التي تم إدخالها من نوع البيانات المتوقعة. إذا كان الرقم متوقعاً، ينبغي أن يضمن تطبيق العميل وجود رقم يتم إرجاعه بالفعل. إذا كانت السلسلة النصية متوقعة، فتأكد من أن طول السلسلة النصية صحيح، وأنها لا تحتوي على أي بيانات ثنائية بداخلها. ينبغي أن يتمكن تطبيق العميل من التحقق من صحة جميع البيانات التي يمررها المستخدم. يمكن إجراء التحقق عن طريق إبلاغ المستخدم بالمشكلة والسماح للمستخدم بتصحيحها، أو عن طريق التعطل بصورة آمنة، إذ يتم إرجاع الخطأ وعدم إرسال أوامر إلى قاعدة البيانات أو نظام الملفات.
بينما ينبغي أن يكون إصلاح رمز تطبيقك هو الأولوية دائماً، فقد لا يكون ذلك ممكناً في بعض الحالات، لذا فإن وجود ميزة الحماية من المخاطر المتقدمة يمكن أن توفر طبقة إضافية من الحماية لبياناتك الحساسة.