كيفية الحد من هجوم SQL Injection

اقرأ في هذا المقال


يعد إدخال (SQL) نوعًا من الهجمات الإلكترونية حيث يستخدم المتسلل جزءًا من رمز (SQL) لغة الاستعلام الهيكلية للتعامل مع قاعدة البيانات والوصول إلى المعلومات التي يحتمل أن تكون ذات قيمة، كما يعد حقن (SQL) طريقة هجوم شائعة للخصوم، ولكن من خلال اتخاذ الاحتياطات المناسبة مثل التأكد من تشفير البيانات وحماية تطبيقات الويب الخاصة واختبارها، والاطلاع دائما على التصحيحات، فهنالك العديد من الخطوات ذات مغزى نحو الاحتفاظ بيانات آمنة، كما إنه أحد أكثر أنواع الهجمات انتشارًا وتهديدًا لأنه يمكن استخدامه ضد أي تطبيق ويب أو موقع ويب يستخدم قاعدة بيانات تستند إلى (SQL).

كيفية منع هجمات حقن SQL

التدريب والحفاظ على الوعي

للحفاظ على تطبيق الويب الخاص آمنًا، يجب أن يكون كل من يشارك في إنشاء تطبيق الويب على دراية بالمخاطر المرتبطة بـ (SQL Injections)، حيث يجب أن يتم توفير تدريبًا أمنيًا مناسبًا لجميع المطورين وموظفي ضمان الجودة.

عدم الوثوق بأي مدخلات مستخدم

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

استخدام القوائم البيضاء وليس القوائم السوداء

عدم القيام بتصفية مدخلات المستخدم بناءً على القوائم السوداء، حيث سيجد المهاجم الذكي دائمًا طريقة للتحايل على القائمة السوداء الخاصة بالمستخدم، كما إذا كان ذلك ممكنًا، يجب التحقق من إدخال المستخدم وتصفيته باستخدام قوائم بيضاء صارمة فقط.

اعتماد أحدث التقنيات

عدم التمتع بتقنيات تطوير الويب القديمة بحماية (SQLi)، حيث يجب استخدام أحدث إصدار من بيئة التطوير واللغة وأحدث التقنيات المرتبطة بتلك البيئة واللغة والمحافظة على قواعد البيانات محدثة لأحدث التصحيحات المتاحة هذا يمنع المهاجمين من استغلال نقاط الضعف والأخطاء المعروفة الموجودة في الإصدارات القديمة.

توظيف الآليات التي تم التحقق منها

عدم محاولة بناء حماية (SQLi) من البداية، حيث يمكن أن توفر معظم تقنيات التطوير الحديثة آليات للحماية من (SQLi)، واستخدم مثل هذه الآليات بدلاً من محاولة إعادة اختراع العجلة، على سبيل المثال، استخدم الاستعلامات ذات الإجراءات المخزنة.

عدم استخدام لغة SQL الديناميكية

يتضمن هذا تجنب وضع المدخلات المقدمة من المستخدم مباشرة في عبارات (SQL)و تفضيل البيانات المعدة والاستعلامات المحددة، والتي تكون أكثر أمانًا، حيث عادةً ما تكون الإجراءات المخزنة أكثر أمانًا من (SQL) الديناميكي.

تعقيم المدخلات المقدمة من المستخدم 

المقصود بها الهروب الصحيح من تلك الشخصيات المشتبه بها والمشكوك بإمرها والتحقق من أن نوع البيانات المقدمة يطابق النوع المتوقع، كما يجب تقييد أذونات قاعدة البيانات والامتيازات وضبط إمكانيات مستخدم قاعدة البيانات على الحد الأدنى المطلوب، سيحد هذا مما يمكن للمهاجم فعله إذا تمكن من الوصول ويجب أيضاًً تجنب عرض أخطاء قاعدة البيانات مباشرة على المستخدم يمكن للمهاجمين استخدام رسائل الخطأ هذه للحصول على معلومات حول قاعدة البيانات.

استخدام جدار حماية تطبيق الويب (WAF) 

(WAF) هو جدار يحمي تطبيق الويب ويوفر الحماية للتطبيقات التي تواجه الويب، حيث يمكن أن يساعد في تحديد محاولات حقن (SQL)، بناءً على الإعداد يمكن أن يساعد أيضًا في منع محاولات حقن (SQL) من الوصول إلى التطبيق وبالتالي قاعدة البيانات، كما يجب استخدام حل اختبار أمان تطبيق الويب لاختبار تطبيقات الويب التي تتفاعل مع قواعد البيانات بشكل روتيني يمكن أن يساعد هذا القيام بذلك في اكتشاف الأخطاء أو الانحدارات الجديدة التي قد تسمح بإدخال (SQL).

  • “WAF” اختصار ل”web application firewall”

المسح بانتظام باستخدام برنامج Acunetix

قد يتم تقديم إدخالات (SQL) بواسطة المطورين او من خلال مكتبات او وحدات او برامج خارجية، حيث يجب على المستخدم حينها فحص تطبيقات ويب بانتظام باستخدام ماسح ضوئي لنقاط ضعف الويب مثل (Acunetix)، وهو برنامج يكشف ادراج الملفات تلقائيا.

إزالة عناصر التعليمات البرمجية الضارة المحتملة

مثل علامات الاقتباس الفردية، إنها فكرة جيدة إيقاف تشغيل رؤية أخطاء قاعدة البيانات على مواقع الإنتاج الخاصة، حيث يمكن استخدام أخطاء قاعدة البيانات مع حقن (SQL) للحصول على معلومات حول قاعدة البيانات الخاصة، ففي حال اكتشاف ثغرة أمنية في حقن (SQL)، على سبيل المثال باستخدام فحص (Acunetix)، فقد لا يتم التمكن من إصلاحها على الفور، على سبيل المثال، قد تكون الثغرة الأمنية في كود مفتوح المصدر.

ما هي المخاطر المرتبطة بحقن SQL؟

إذا تم إكمال هذا الهجوم بنجاح، فمن المحتمل أن تكون عمليات حقن (SQL) ضارة بشكل لا يصدق لأي شركة أو فرد، بمجرد اختراق البيانات الحساسة في هجوم، قد يكون من الصعب استردادها بالكامل، عادةً ما يتم استهداف قواعد البيانات للحقن من خلال أحد التطبيقات مثل موقع الويب الذي يطلب إدخال المستخدم ثم يقوم بالبحث في قاعدة بيانات بناءً على هذا الإدخال، ولكن يمكن أيضًا استهدافها مباشرةً، حيث يمكن  أن يؤدي حقن (SQL) إلى عدد من المخاطر التي قد تشكل تهديدات خطيرة للمؤسس، منها:

  • يقوم المخترق ذو الفاعلية السيئة بحقن (SQL) لحذف البيانات أو الجداول من قاعدة البيانات، في هذه الحالة، حتى في حالة وجود نُسخ احتياطية لقاعدة البيانات، حيث يمكن أن يؤثر حذف البيانات على توفر التطبيق حتى يمكن استعادة قاعدة البيانات، علاوة على ذلك، قد لا تتضمن النسخ الاحتياطية بيانات حديثة.
  • يستخدم المهاجمون حقن (SQL) لتعديل أو تحديث البيانات في قاعدة البيانات وإضافة بيانات إضافية، على سبيل المثال، في حالة تطبيق مالي، يمكن للمهاجم استخدام حقن (SQL) لتغيير أرصدة الحسابات، والأسوأ من ذلك، يمكن للمهاجمين الحصول على حقوق إدارية لقاعدة بيانات التطبيق.
  • إن الخطر الأكثر شيوعًا لهجوم حقن (SQL) هو سرقة بيانات المستخدم، حيث يمكن سرقة عناوين البريد الإلكتروني وبيانات اعتماد تسجيل الدخول ومعلومات التعريف الشخصية (PII) وبيعها على شبكة الإنترنت المظلمة، لذلك فإن الحقن الناجح لـ (SQL) يشكل تهديدًا ليس فقط للمؤسسة ولكن أيضًا لمستخدميها، حتى انه وبعد 20 عامًا من اكتشاف حقن (SQL)، فإنها تظل أحد الاهتمامات الأساسية عندما يتعلق الأمر بخرق البياناتوأمان البيانات، في الواقع، يُظهر تحليل اتجاهات الهجوم الأخير ارتفاع هجمات حقن SQL بنسبة 47٪.
  • “PII” اختصار ل”personally identifiable information”.

إجراءات المهاجم الناجح على هدف مخترق

  • تجاوز المصادقة.
  • تسريب او سرقة البيانات.
  • تعديل البيانات أو إتلافها.
  • حذف البيانات.
  • تشغيل التعليمات البرمجية التعسفية.
  • الحصول على حق الوصول إلى الجذر للنظام نفسه أي الى الأساس.

شارك المقالة: