A03:2021 – الحقن

العوامل

ربطها مع CWEs	الحد الأقصى للحدوث	متوسط معدل الحدوث	التغطية القصوى	متوسط معدل التغطية	متوسط استغلال الثغرات	متوسط التأثير	إجمالي التكرار	إجمالي نقاط الضعف CVEs
33	19.09%	3.37%	94.04%	47.90%	7.25	7.15	274,228	32,078

نظرة عامة

هجمات الحقن تحتل المركز الثالث، حيث أن 94٪ من التطبيقات التي تم فحصها مهدّدة بصنف واحد أو أكثر من هجمات الحقن المرتبطة مع CWE-79، CWE-89، CWE-73

الوصف

يكون البرنامج معرض للإصابة بهذه الهجمات عندما:

إذا كانت المدخلات المزوّدة من المستخدم غير مُتحقّق منها أو غير موثوقة، أو لم يتم تصفيتها من قِبل البرنامج.
تمرير طلبات الاستعلامات الديناميكية أو استدعاء بيانات غير محدّدة المعاملات (Non-Parameterized) بشكل مباشر إلى مترجم الأوامر بدون استخدام آلية واعية تضمن تهرب المدخلات من التفاعل مع مترجم الأوامر "Context-aware escaping".
المدخلات الضَّارة التي يتم استخدامها والبحث عنها في (Object-relational mapping ORM) والتي قد تقوم بتسريب بيانات إضافية غير مطلوبة أو بيانات حساسة.
تمرير المدخلات الضَّارة بشكل مباشر أو بشكل متسلسل غير مباشر، قواعد البيانات العلائقية "SQL" أو الأوامر التي تحتوي على هياكل وبيانات مشبوهة في طلبات الاستعلام الديناميكية "dynamic queries” أو الأوامر أو الإجراءات المخزّنة

من أشهر أنواع الحقن : الـ SQL، NoSQL، سطر الأوامر في أنظمة التشغيل، خرائط ربط الكائنات بقواعد البيانات العلائقية "Object-relational mapping”، LDAP، ولغات البرمجة التعبيرية "EL"، مكتبات التنقّل خلال مخططات الكائنات"OGNL". مبدأ "الحقن" مُتطابق في جميع لغات البرمجة وفي جميع المفسّرات، مراجعة مصدر الشّفرة المصدرية هي أفضل طريقة لاكتشاف ما إذا كان التطبيق البرمجي عُرضة للإصابة بثغرة الحقن. يوصَّى بشدّة بالفحص التلقائي لكل المعاملات تروسيات صفحات الويب، الروابط التشعبيّة "URL"، وملفات تعريف الارتباط "Cookies"، و JSONو الـ SOAP ومدخلات معطيات الـ XML. المنظمات بإمكانها إضافة أدوات الفحص ثابتة المصدر"SAST" وأدوات الفحص الديناميكية للتطبيقات البرمجية "DAST"واستخدامها في مسارات CI/CD، لتحديد العيوب الموجودة من قبل عملية طرح المنتج للاستخدام.

كيفية الحماية منها

لتفادي هجمات الحقن يجب الفصل والتفّريق بين كل من البيانات والأوامر والاستعلامات.
ُفضّل استخدام واجهات برمجة تطبيقات (API) آمنة، وذلك لتفادي استخدام مفسّر الأوامر كُلّيًا، و توفير واجهة إدخال ذات معاملات " Parametrized Interface " أو الانتقال إلى استخدام كائنات الـ "Relational Mapping Tools (ORMs)".
ملاحظة: حتى في حال استخدام المعاملات" Parameterized” الإجراءات المخزّنة قد لا تزال قاعدة البيانات مُعرّضة لهجمات الحقن في حال كانت الـ PL/SQL أو T-SQL قابلة لتنفيذ الاستعلامات المتسلسلة "الغير مباشرة " أو تنفيذ تعليمات برمجية ضارّة من خلال EXECUTE IMMEDIATE أو exec ().
استخدام عمليات التحقّق من المدخلات الإيجابية و المرتبطة ب "قوائم السماح/القوائم البيضاء" من طرف الخادم. لكن هذه لا تعتبر حماية متكاملة حيث أن هناك العديد من البرامج تتطّلب رموز خاصة "Special Characters" مثل حقل النص (TextArea) أو واجهات تطبيقات البرامج (APIs) لتطبيقات الهواتف.
في حال وجود استعلامات ديناميكية متبقية، قم بتصفية الاستعلام من الرموز الخاصة من خلال استخدام صيغة برمجية "Syntax " لتصفية المدخلات المحددة إلى مفسّر الأوامر.
ملاحظة: هيكلة SQL مثل أسماء الجداول أو الأعمدة وغيرها، لا يمكن إجراء عوامل التصفية عليها، لذلك يجب الحذر من هياكل البيانات القادمة من المستخدم حيث أنها تعتبر خطرة. وهذا خطأ شائع عند كتابة-تقارير البرمجيات.
ضع حدودا و أو ضوابط تحكّم أخرى عند استخدام الاستعلامات داخل SQL، لتجنّب كشف السجلات الحساسة في حال وجود هجمات حقن الـ SQL

أمثلة على سيناريوهات الهجوم

سيناريو #1: برنامج يستخدم بيانات غير موثقة في بناء الاستعلام في قاعدة بيانات الSQL والتي قد يعرضها للحقن:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

سيناريو #2: الثقة العمياء للبرنامج في إطار العمل (Framework) وقد تؤدي تلك الاستعلامات إلى ثغرات الحقن مثل Hibernate Query Language (HQL):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

في كلتا الحالتين السابقتين، المُخترق قام بتعديل قيمة متغيّر الـ id في المتصفح لإرسال ‘ UNION SELECT SLEEP(10);-- . مثلاً:

http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--

وهذا ينتج تغيير في معنى الاستعلام للحصول على جميع السجلات من جدول الحسابات. وقد يستغلّها المُخترق بشكل آخر لتعديل أو حذف أو حتى استدعاء العمليات المخزّنة.