الـ SQL Injection ، سلاح الدمار الشامل للمواقع

ما هو الـ SQL Injection

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

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

سنتحدث في هذه المقالة المطولة بعض الشيء عن واحد من أشد الأخطار فتكاً في تطبيقات الويب ، حيث يمكن لهذه النوعية من الهجمات أن تقوم بمسح قاعدة بيانات كاملة ، او سرقة محتوياتها ، بتعديل بسيط في نماذج الإدخال ، أو بتغيير بسيط جدا في عنوان الموقع !!

الـ SQL Injection أو إن صح لنا تعريبه بـ " حقن الـ SQL " ، هو نوع من الهجمات يعتمد على إضافة شيفر SQL الى المتغيرات المررة للنظام ، بحيث يتم تنفيذ هذه الجزئية من الشيفرة مع الشيفرة الأساسية الموجودة في النظام ، لتوضيح الصورة ، سنطرح هذا المثال المكتوب بلغة PHP بإستخدام نظام قواعد البيانات MySQL :



" method=post>







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

الأن تخيل لو أن المخترق قام بإدخال التالي في حقل كلمة المرور :

' OR username LIKE '%


بذلك ستصبح جملة الإستعلام في أصل البرنامج بهذا الشكل :

SELECT * FROM users WHERE username=' ' AND password= ' ' OR username LIKE '%'



جملة الإستعلام ستكون نتيجتها أكثر من سجل واحد بكل تأكيد ، ببساطة ستكون نتيجتها كافة السجلات ، لأن أي سجل في قاعدة البيانات سيطابق شروط هذا الإستعلام ، بسبب وجود الشرط OR

هذا يعني أن المخترق سيتمكن من الوصول الى المنطقة التي لا يمكن الا للأعضاء أن يصلوا اليها !!

أتمنى أن يكون هذا المثال المبسط قد أوضح بشكل كامل ما هو المقصود بالـ SQL Injection و مدى خطورته


ما هي مخاطر الـ SQL Injection

مخاطر الـ SQL Injection تتنوع بحسب وظائف التطبيق نفسه ، فعلى سبيل المثال لنفترض أن لدينا موقع لتسجيل الطلاب و الإستعلام عن درجاتهم و مستوياتهم ، يمكن القيام بما يلي عن طريق الـ SQL Injection :

1- الإستعلام عن درجة طالب بدون معرفة كلمة المرور الخاصة به !!

2- حذف سجل طالب أو مجموعة من الطلاب

3- حذف جدول كامل من قاعدة البيانات

4- إدراج سجل جديد في قاعدة البيانات

5- إكتشاف مسميات الجداول و تركيب و بنية قاعدة البيانات عن طريق التجربة

6- التعديل بمحتوى سجل محدد و تغيير بياناته !!

هذه مجموعة بسيطة من الكوارث التي قد تسببها هذه النوعية من الهجمات ، و فيما يلي سنستعرض بعض الأمثلة

مثال على أمر يقوم بسحب البيانات عن طريق أمر SQL مدمج :

SELECT Id,Title,Abstract FROM News WHERE Category=1 UNION SELECT 1,UsrName,Passwd FROM Usr

الجزء الملون من الإستعلام هو المتغيير الممرر الى البرنامج ، حيث يقوم المخترق في هذا المثال بتمرير أمر SQL آخر وظيفته جلب إسم المستخدم و كلمة المرور من الجدول Usr ، الأن أصبح المخترق قادر على رؤية أسماء المستخدمين و كلمات مرورهم جميعها ... هل لك أن تتخيل ذلك ؟؟؟


مثال على أمر يقوم بإدراج بيانات مستخدم جديد :

SELECT email, passwd, login_id, full_name
FROM members
WHERE email = 'x';
INSERT INTO members ('email','passwd','login_id','full_name')
VALUES ('btree@devhall.com','hello','Btree','Binary Tree');--';


الجزء الملون يوضح المتغير الذي مرره المخترق الى النظام كقيمة للحقل email الذي من المفترض كقيمة نظامية أن يحتوي على بريد إلكتروني و ليس على إستعلام SQL كما فعل هذا المخترق في المثال السابق ، هذه الشيفرة التي أضافها المخترق تقوم بإضافة عضو جديد الى الموقع بالبيانات المذكورة !!!


مثال يقوم بحذف جدول كامل من قاعدة البيانات !!

SELECT fieldlist
FROM customers
WHERE name = 'Binary Tree';



الشيفرة السابقة تعمل بشكل سليم و نظامي ، حيث تم تمرير قيمة Binary Tree للمتغير في حقل name ، لكن تخيل لو قام المخترق بالتالي :

SELECT fieldlist
FROM customers
WHERE name = '\''; DROP TABLE users; --';



لو قام المستخدم بإدخال العبارة الملونة بالأحمر في حقل الإسم ، هذا يعني أن جدولا بأكمله سيتم حذفه من قاعدة البيانات !! كارثة اليس كذلك ؟


أعتقد أن هذه الأمثلة كافية لإيقاظ المبرمجين الغافلين عن المخاطر الفعلية وراء مدخلات المستخدمين


ما هي الحلول ؟

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

1- لا تقم بعرض رسائل خطأ تفصيلية في نظامك ، بعض المبرمجين للاسف يقوم بعرض رسائل خطأ تبين أين كانت المشكلة في الإستعلام ، في أي سطر ، و في أي جدول من قواعد البيانات ، هذه التفاصيل تعتبر تفاصيل ثمينة جدا للمخترقين ، حيث سيتمكنون من خلالها تكوين صورة كاملة عن بنية قاعدة البيانات الخاصة بنظامك و معرفة التركيب الفعلي لأوامر الإستعلامات حتى و إن لم يروا الشيفرة المصدرية !!


2- تحقق من كافة المدخلات التي يدخلها المستخدم ، على سبيل المثال ، اذا كان من المفترض أن يدخل المستخدم في هذا الحقل رقما ، فلا تسمح له بتاتا بإدخال أي شيئ عدا الأرقام ، أو إن كان هذا الحقل مخصص لعناوين البريد الإلكتروني ، فلا تسمح بكتابة شيء غير البريد الإلكتروني عن طريق التحقق بواسطة الـ Regular Expressions ، أيضا اللغات الحديثة للتطوير توفر مجموعة من الدوال تخلص المدخلات من الشوائب الغير نظامية في الإدخال ، فعلى سبيل المثال ، في نظام قواعد البيانات MySQL يمكن إستخدام الدالة التالية :



safeEscapeString($parameter)