كيف يمكنني تجنب هجمات حقن SQL؟

Question

بالأمس كنت أتحدث مع مطور، وذكر شيئا عن تقييد الإدراج في مجال قاعدة البيانات، مثل سلاسل مثل -- (ناقص ناقص).

في نفس النوع، ما أعرفه هو أن هذا نهج جيد للهروب من HTML Chars مثل <, > الخ لا --. وبعد هل هذا صحيح؟ هل يجب أن أشعر بالقلق --, ++ب هل هو أكثر مثل الأسطورة أو الأشياء القديمة؟

---

تحديث

شكرا جزيلا لجميع الإجابات، من السهل أن نفهم مثل هذا لأنني جديد من جديد لكل هذا. حسنا، أن تكون أكثر تحديدا في هذه الحالة كانت مناقشتنا حول موقع الويب الخاص بنا و C # ASP.NET MVC النمو، لذلك هناك معقد فتح نموذج حساب هناك مع معلومات مهمة، لذلك لست متأكدا مما إذا كان MVC باستخدام LinQ إلى واجهة مع قاعدة البيانات تأتي بالفعل مع هذا النوع من الحماية أم لا. لذلك إذا كان أي شخص يمكن أن يوفر بعض التلميحات حول هذا الموضوع، فسيكون ذلك رائعا. شكرا لك مرة أخرى

Answer 1

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

يمكنك العثور على بعض المقالات الجيدة حول موضوع SQL المحمي هنا:

https:/blog.codinghorroror.com/give-me-parameterized-sql-or-give-me-death/

http://www.codeproject.com/kb/database/parameterizesadhocsql.aspx.

الآن بعد أن ذكرت أنك تعمل مع ASP.NET يمكنني أن أعطيك بعض الروابط التي تتعامل على وجه التحديد مع حقن SQL في ASP.

https:/dzone.com/articles/aspnet-preventing-sql-injectio. http://www.codeProject.com/kb/aspnet/sql_injection_.aspx؟msg=3209511.

فيما يلي مقالة أكثر عمومية حول جعل ASP أكثر أمانا:http://www.codeProject.com/kb/web-security/securation_asp_net_apps.aspx.

وبالطبع مقالة MSDN حول حقن SQL:http://msdn.microsoft.com/en-us/library/ms998271.aspx.

Answer 2

يمثل حقن SQL مخاطرة أمنية عالية لمعظم مواقع الويب التي تتيح للمستخدمين مع المعلمات بخ الوضع يتم تنفيذها في قاعدة بيانات.

مثال بسيط سيكون:

حقل الإدخال "الاسم: _________

"SELECT * FROM tblCustomer WHERE Name = '" + nameInputField + "'"

لذلك إذا اكتبت في "بوب" لدينا

"SELECT * FROM tblCustomer WHERE Name = 'Bob'"

ولكن إذا اكتبت "؛ إسقاط جدول TBLCustomer"، ونحن في نهاية المطاف مع المزيد من الشرير

"SELECT * FROM tblCustomer WHERE Name = ''; DROP TABLE tblCustomer"

هناك الكثير من الطرق لتجنب هذه المشكلات، ويتم تصميم العديد من الكثيرين في أي لغة تستخدمها - هكذا تفكر في جميع إمكانيات المراوغة "؛" - "-"، "/ *"، إلخ، حاول استخدام شيء ما موجود أصلا.

يصرخ هذه اللغة التي تستخدمها وأنا متأكد من أننا نستطيع أن أقول لك كيفية تجنب هذه الهجمات.

Answer 3

كان يتحدث حقن SQL الهجمات، كما هو صحيح تماما فيما قال.

المشكلة ليست مع هذه البيانات الموجودة في قاعدة البيانات، ولكن في تمرير بيانات الإدخال مباشرة إلى قاعدة البيانات دون تعقيمها.

دون تنظيفه، إذا مر شخص ما في سلسلة تنتهي ب ; يمكنهم بعد ذلك اتباع أي شيء يريدون (select * from sys.objects, ، على سبيل المثال) أو شيء أكثر ضارة، مثل إسقاط بعض الجداول.

من الصعب حذره بالكامل، ولكن إذا كنت تستخدم مكتبة DB جيدة من التعليمات البرمجية الخاصة بك واتبع الممارسات المعروفة، مثل استخدام الاستفسارات المتخصصة التي تحد من الضرر المحتمل.

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

Answer 4

لا يوجد شيء "خطير" حول إدراج سلسلة تحتوي على -- في قاعدة البيانات.

إنه أمر خطير اي شى في جدول قاعدة البيانات يأتي مباشرة من إدخال المستخدم دون معالجة ذلك، وإلا فإنك تترك نفسك مفتوحة هجمات حقن SQL. وبعد مثال: يتيح الرمز من نوع المستخدم باسمه في حقل، وأنواع المستخدمين:

Joe '); drop table users; commit transaction; --

ثم يضع المبرمج أنه في قاعدة بيانات MySQL الخاصة بهم

conn.execute("insert into users (username) values ('" + userInput + "')");

فقاعة قام المستخدم بحذف جدول المستخدمين (على افتراض وجود تسجيل دخول قاعدة البيانات حقوق للقيام بذلك، والذي لا ينبغي ذلك - ولكن هذا موضوع مختلف)، لأن المبرمج لم يضمن أن يتم هرب السلسلة من المستخدم بشكل صحيح، و لذلك تم إرسالها مباشرة إلى محرك DB والمهاجم يضحك جيدا. :-)

استخدم مهما كانت الأدوات التي توفرها بيئتك تأكد من هربت الأوتار بشكل صحيح. على سبيل المثال، يستخدم JDBC PreparedStatement فئة لهذا. سيكون له معظم البيئات شيئا مشابها.

Answer 5

استخدام الاستعلامات المعلمة. تمثل هذه الاستفسارات المتغيرات كصحة نائبة في SQL، مثل select * from person where name = ?. وبعد بعد إنشاء استعلام SQL، يمكنك تعيين قيم المعلمة في الاستعلام. التأكد من الاستعلامات المعلمة أن كل ما تم استبداله لن يعتبر العنصر النائب كجزء من عبارة SQL.

يرى مقالة جيف اتوود للحصول على نظرة عامة جيدة على الاستفسارات المعلمة.

Answer 6

ليس خطرا طالما كنت تفلت بشكل صحيح من البيانات عند إجراء إدراج / تحديث / ...

والهروب من أحرف HTML هو ليس نهج جيد. تخيل أنك كتبت دالة تهرب من هذه الشخصيات وقد تخزن بعض النص الفارق في قاعدة البيانات. ثم لاحظت أن وظيفتك لم تفلت عن "<"، لذلك قمت بتغيير الوظيفة ... الآن ما يحدث للسجلات الموجودة بالفعل في قاعدة البيانات؟ - ستبقى شخصياتهم "<'" غير متجانسة. هكذا، أبدا الهروب من نص قبل تخزينه في قاعدة البيانات (الهروب من استعلام SQL، بالطبع). يجب أن يحدث الهروب عند إنتاج صفحة HTML / XML / ... من النص، أي بعد الاستعلام عن النص الأصلي من قاعدة البيانات!