حقن SQL

حقن

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

الخطأ الكلاسيكي

مثال الكتاب المدرسي. يقبل أحد التطبيقات اسم مستخدم من نموذج تسجيل الدخول ويبحث عنه:

query = "SELECT * FROM users WHERE username='" + input + "';"

إذا كان input هو alice، فإن الاستعلام يصبح:

SELECT * من المستخدمين حيث اسم المستخدم = 'alice'؛

Normal. ولكن إذا كان input هو alice' OR '1'='1، يصبح الاستعلام:

SELECT * FROM users WHERE username='alice' OR '1'='1';

The OR '1'='1' صحيح دائمًا. يقوم الاستعلام بإرجاع كل مستخدم في الجدول. باستخدام الحمولات الأكثر تعقيدًا، يمكن للمهاجم تفريغ الجداول أو تعديل السجلات أو التصعيد بشكل أكبر.

فئات الهجوم

• Classic / SQLi داخل النطاق. تظهر نتائج الاستعلام المُدخل في استجابة التطبيق. يقرأ المهاجم البيانات مباشرة.
• Blind SQLi. لا تظهر أي بيانات في الاستجابة، ولكن يتغير سلوك التطبيق بناءً على ما إذا كان الاستعلام الذي تم إدخاله يُرجع صحيحًا أم خطأ. يستخرج المهاجم البيانات بت واحد في كل مرة عن طريق طرح أسئلة مثل "هل الحرف الأول من كلمة مرور المسؤول 'a'؟"
• SQLi الأعمى المستند إلى الوقت. يستخدم المهاجم SLEEP() أو ما يعادله لجعل قاعدة البيانات تستجيب ببطء عندما يكون الشرط صحيحًا. حتى أن عملية استخراج البيانات أبطأ، ولكنها تعمل عندما لا يقدم التطبيق أي تعليقات استجابة.
• Out-of-band SQLi. يخدع المهاجم قاعدة البيانات لإجراء اتصال شبكة خارجي (بحث DNS، طلب HTTP) الذي يسرب البيانات إلى خادم يتحكم فيه.
• Second-order SQLi. يتم تخزين المدخلات الضارة في قاعدة البيانات أولاً، ثم يتم قراءتها لاحقًا واستخدامها في استعلام آخر بشكل غير آمن. يحدث الإدخال في سياق مختلف عن الإدخال.

الإصلاح: استعلامات ذات معلمات

الطريقة الصحيحة للاستعلام عن قاعدة بيانات بإدخال المستخدم هي استخدام العناصر النائبة للمعلمات، وعدم ربط السلاسل مطلقًا. في كل اللغات بشكل أساسي:

// Python (psycopg2)
cursor.execute("حدد * من المستخدمين حيث اسم المستخدم=%s"، (الإدخال،))

// جافا
stmt = conn.prepareStatement("SELECT * FROM users WHERE username=؟");
stmt.setString(1, input);

// جافا سكريبت (صفحة)
Client.query("SELECT * FROM users WHERE username=$1", [input]);

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

هذا يعمل. لقد كان هذا هو النهج الموصى به لمدة عقدين من الزمن. التحدي ليس في التقنية؛ إنها تتأكد من أن كل استعلام في قاعدة التعليمات البرمجية يستخدمه.

ORMs ليست آمنة تلقائيًا يستخدم

Object-Relational Mappers (ActiveRecord، وSequelize، وHbernate، وSQLAlchemy) استعلامات ذات معلمات افتراضيًا، وهو أمر رائع. لكن كل ORM لديه فتحات هروب: أساليب

• raw() التي تأخذ سلاسل SQL عشوائية
• عبارات ORDER BY المستندة إلى String (لا يمكن تحديد معلمات أسماء الأعمدة)
• أسماء الجداول المحرفة في استعلامات
• الإجراءات المخزنة نفسها متسلسلة

تظهر أخطاء SQLi الحديثة عادةً في حالات الحافة هذه، وليس في مسار كود CRUD الرئيسي.

NoSQL حقن

النمط ليس فريدًا بالنسبة لـ SQL. MongoDB، وRedis، وElasticSearch، وGraphQL — أي لغة استعلام تقبل الإدخال المنظم من المستخدمين يمكن حقنها إذا لم يتم التحقق من صحة الإدخال. تعد عوامل $ne و$gt و$regex من MongoDB بمثابة ناقلات حقن شائعة عندما لا يتم فحص حمولات JSON بشكل صارم. الاستعلامات:

• Lحسابات قاعدة البيانات ذات الامتيازات الشرقية. يجب أن يتصل التطبيق بمستخدم لديه الأذونات التي يحتاجها فقط. تستخدم مسارات القراءة فقط بيانات اعتماد للقراءة فقط. يحد من الضرر عند استغلال SQLi.
• التحقق من صحة الإدخال. تقييد المدخلات بالتنسيقات المتوقعة. مفيدة ولكنها ليست كافية من تلقاء نفسها.
• جدران حماية تطبيقات الويب (WAFs). محاولات SQLi الواضحة لمطابقة الأنماط. يمكن تجاوز المهاجمين ولكنهم بطيئون.
• تحليل ثابت. أدوات تفحص المصدر بحثًا عن استعلامات متسلسلة. تقوم IDEs الحديثة بوضع علامة على هذه.
• تقوية قاعدة البيانات. تعطيل الميزات غير الضرورية (xp_cmdshell في MSSQL، والامتدادات الخطيرة في PostgreSQL).

Famous SQLi حوادث

• 2007 TJX - 94 مليون بطاقة ائتمان. بدأت بتسوية Wi-Fi ولكن تم استخدام SQLi للتسلل من قواعد البيانات الداخلية.
• 2008 Heartland - 130 مليون سجل بطاقة. أعطى SQLi وصولاً مبدئيًا إلى الشبكة.
• 2012 LinkedIn - تم سحب 117 مليون تجزئة لكلمات المرور عبر SQLi.
• 2017 Equifax - ثغرة أمنية في Apache Struts، لكن SQLi كان جزءًا من بيانات ما بعد التسوية الترشيح.
• طوال عام 2020 - عدد لا يحصى من الانتهاكات الصغيرة في شركات SaaS ومواقع التجارة الإلكترونية والوكالات الحكومية.

هذه الفئة عمرها عقود وما زالت حية إلى حد كبير.