أنشئ حسابًا أو سجّل الدخول للانضمام إلى مجتمعك المهني.
هو اضافة Sql statement الى ال Query الخاص بك ، عادة مايقوم المخترق بكتابة جملة (اس كيو ال) في Query string الخاص بك فترسل تلك الاوامر الى ال Database فيتم تنفيذها .
تفادي Sql injection
- في حال ان ال Query string يحتوي على قيمة عددية يمكن فحصها في Page Load
- يمكنك استخدام ال Query string الى جملة ( اس كيو ال )الخاصة بك عن طريق استخدام الـ parameters
الحل الافضل والامن هو عدم كتابة جمل (اس كيو ال) في صفحات الويب ويتم استخدام Procedures فقط ، ثم يتم تغيير خصائص ال Database بحيث لا تنفذ اوامر ال (اس كيو ال) وانما تنفذ Procedures فقط .
حقن سكل هو تقنية حقن رمز التي قد تدمر قاعدة البيانات الخاصة بك.
طريقة لاستغلال ثغرة محتملة في جميع التطبيقات التي تتعامل مع قاعدة البيانات . من ضمن هذه التطبيقات نجد مواقع الويب . إذ يمكن للمهاجم التعامل مباشرة مع قاعدة البيانات و إجراء استعلامات غير متوقعة من طرف المبرمج
هو نوع من اختراق لغة الاستعلام البنيوية
حقن sql هو وضع التعليمات البرمجية الخبيثة في عبارات sql، ولتجنب ذلك يجب أن تكون عبارات ال sql مقيدة بشكل جيد
هذا النوع من أختراق لغة الاستعلام البنيوية يحصل عندما لا يتم تصفية مدخلات المستخدم من الرموز الخاصة
التي يتم أدراجها داخل جمل بصيغة لغة الاستعلام البنيوية والتي يمكن ان تؤدي للتلاعب بهذه الجمل المدخلة لقاعدة البيانات من قبل مستخدمي
هووضع علامات واكواد خبيثة للدخول الى البيانات بطريقة خبيثة في برمجيات SQL .
الحل الأنسب هو عدم كتابة جمل (س كيو ل ) في الويب واستخدام Procedures فقط
هو اضافة Sql جمله الى ال Query الخاص بك ، عادة مايقوم المخترق بكتابة جملة (اس كيو ال) في Query string الخاص بك فترسل تلك الاوامر الى ال Database
حقن القواعد باختصار هو استغلال الهكر لبعض الاخطاء المبرمج في كتابة كود بي أتش بي مما يؤدي الي كتابة اوامر قاعدة الابيانات واستخراج البيانات
حقن إس كيو إل
بالإنجليزية SQL INJECTION
أو حقن تعليمات الاستعلام البنيوية (SQL) بإضافات.
الهدف هو استغلال أي ثغرة أمنية موجودة بطبقة قاعدة البيانات التابعة لأي برنامج
(DATABASE LAYER)
. هذه الثغرات ممكن أن تكون حاضرة عندما لا يتم تصفية مدخلات المستخدم لبعض الحروف والرموز الخاصة (ESCAPE CHARACTERS)
المضمنة داخل جمل لغة الاستعلام البنيوية، أو ان لا يتم مراجعة نوعية المدخلات ان كانت نصية ام عددية (STRONGLY TYPED)
مما يسبب عدم التكهن بنتيجة تنفيذها.
أنواع ثغرات اختراق لغة الاستعلام البنيوية
هذا النوع من أختراق لغة الاستعلام البنيوية يحصل عندما لا يتم تصفية مدخلات المستخدم من الرموز الخاصة
(ESCAPE CHARACTERS)
التي يتم أدراجها داخل جمل بصيغة لغة الاستعلام البنيوية والتي يمكن ان تؤدي للتلاعب بهذه الجمل المدخلة لقاعدة البيانات من قبل مستخدمي البرنامج. الجملة التالية تبين هذه الثغرة
SELECT*FROMusersWHEREname=' + userName + ';هذه الجملة سوف تستدعي جميع السجلات الخاصة باسم المستخدم (userName) من جدول (users), لكن إذا تم تغير المتغير (userName) بشكل معين وباستخدام الرمز الخاص من قبل المستخدم المخترق (MALICIOUS USER), فمن الممكن لهذه الجملة ان تفعل أكثر مما هو منوي عليه, مثلا يمكن استبدال قيمة المتغير (userName) بالجملة الأتيةa' or 't'='t
وبالتالي تصبح الجملة كالاتي:
SELECT*FROM users WHERE name ='a'or't'='t';
أذا تم أستخدام الجملة السابقة بأجراء التأكد من هوية المستخدم
(AUTHENTICATION PROCEDURE),
فمن الممكن أستخدام هذه الطريقة للحصول على الصلاحية لأن نتيجة المعادلة 't'='t' هي دائما صحيحة
(TRUE).
معظم خوادم لغة الاستعلام البنيوية (SQL SERVERS)
تسمح بتنفيذ عدة جمل في آن واحد وبالتالي يمكن حقن أي جملة صحيحة عن طريق أستخدام هذه الطريقة بإضافة الجملة إلى نهاية المدخل, مثلا يمكن لقيمة (userName)
في الجملة الاتية أن تتسبب بمحو جدول المستخدمين (users)
من قاعدة البيانات بالأضافة لأظهار جميع بيانات جدول(data):
a'; DROP TABLE users; SELECT * FROM data WHERE name LIKE '%
وبالتالي تصبح الجملة كالاتي:
SELECT*FROM users WHERE name ='a'; DROPTABLE users; SELECT*FROMdataWHERE name LIKE'%';
بعض تطبيقات لغة الاستعلام البنيوية الأخرى لا تسمح بتنفيذ عدة أوامر في جملة واحدة للحماية من المخترقين ومنعهم من حقن جمل الاستعلام بشكل منفصل, ولكن هذا لا يمنعهم من تعديل هذه الجمل.
معالجة نوع الحقل الخاطئة
هذا الشكل من الاختراق يحصل عندما لا يتم التأكد من نوع الحقل المدخل من قبل المستخدم. يمكن لهذا الاختراق ان يحصل مثلا عند استخدام حقل من نوع عددي
(NUMERIC)
في جملة الاستعلام, ولكن المبرمج لم يقم بمراقبة مدخلات المستخدم لمعرفة أذا كانت من نوع عددي ام لا. مثلا
SELECT*FROMdataWHERE id =" + a_variable + ";
من الواضح في هذه الجملة ان المقصود من المتغير (a_variable)
ان يكون عدد مرتبط بالحقل (id),
ولكن إذا كان في الحقيقة من نوع نص فمن الممكن ان يتم التلاعب به من قبل المستخدمين كما يشائون, وبالتلي يمكنهم ان يمرروا جمل مخربة. مثال
1; DROPTABLE users
وبالتالي تصبح الجملة كالاتي:
SELECT*FROMdataWHERE id =1; DROPTABLE users;
وعند تنفيذها سوف يتم محو جدول (users)
من قاعدة البيانات.
ثغرات داخل خادم قاعدة البيانات نفسه
من الممكن ان تظهر الثغرات أحيانا داخل برنامج خادم قاعدة البيانات نفسه(VALNERABILITIES INSIDE THE DATABASE SERVER),
كما الحال في (MySQL Server) مع الوظيفة real_escape_chars().
حماية البرامج من أختراق لغة الاستعلام البنيوية
معالجة البرامج وتحصينها
من السهل الحماية من أختراق لغة الاستعلام البنيوية في معظم لغات البرمجة التي تستهدف تطبيقات شبكة الأنترنت. في لغة برمجة
(Perl DBI)
مثلا فأن الوظيفة (DBI::quote)
تستخدم قبل بعض الرموز (ESCAPES SPECIAL CHARACTERS)
بدلا من الرمز
فل نفرض ان المتغير ($sql)
يؤشر على (DBI OBJECT):
$query=$sql->prepare("SELECT * FROM users WHERE name = ".$sql->quote($user_name));
تسمح (DBI)
باستخدام حائزي المكان (PLACE HOLDERS),
والتي تتيح لك ألزام (BIND)
البيانات لجملة معينة منفصلة عن تعريف جملة الاستعلام. اما بالنسبة لقواعد البيانات التي لا تدعم حائزي المكان بالأصل, تقوم (DBI)
بمحاكاتهم (EMULATES)
تلقائيا عن طريق أضافة الوظيفة (DBI::quote)
للقيم
$query=$sql->prepare("SELECT * FROM users WHERE name = ?");
$query->execute($user_name);
الفائدة من هذه الطريقة انه ليس علينا ان نتذكر تطبيق
(DBI::quote)
لكل قيمة,
لأنها أما ملزمة أو منصوصة على نحو ملائم, بحسب نظام أدارة قواعد البيانات
(DBMS)
الذي نستخدمه.
هكذا يتلاشى الموضوع الأساسي في أختراق لغة الاستعلام البنيوية.
معالجة قواعد البيانات وتحصينها (DATABASE REMEDATION)
الأمتيازات الأمنية (SECURITY PRIVILEGES)
إن وضع امتيازات أمنية على قواعد البيانات هو أبسط مثال لحماية قواعد البيانات, وبالتالي القليل من التطبيقات تسمح للمستخدم ان يمحي جدول أو قاعدة بيانات كاملة.
هذه الاستراتيجية لا تحل مشكلة أختراق لغة الاستعلام البنيوية، ولكنها تخفف من شدة الضرر المحتمل.
الإجراءات المخزنة
معظم قواعـد البيانات توفر أمكانية تجهيز جمل الاستعلام في طبقة قواعد البيانات عن طريق الأجراءات المخزنة (STORED PROCEDURES),
عوضا عن استخدام طبقة التطبيق
(APPLICATION LAYER)
لبناء لغة الاستعلام البنيوية بشكل ديناميكي. الأجراءات المخزنة تشمل أجراءات قواعد البيانات متكررة الاستخدام والتي تنادى عن طريق
(TYPED PARAMETER).
هذه الطريقة توفر عدة فوائد أمنية منها: عن طريق استخدام ال
(TYPED PARAMETERS)
فأنه يتم تصفية وفلترة مدخلات المستخدم, بالأضافة إلى أن معظم قواعد البيانات تسمح للأجراءات المخزنة بالتنفيذ تحت أمتيازات أمنية معينة, مما يقيد أمكانية قيام التطبيق بعمل اي شيء خارج نطاق الأعمال المحددة مسبقا في الأجراءات المخزنة.
ومع كل هذا فان هذه الطريقة لا تحل مشكلة أختراق لغة الاستعلام البنيوية بشكل كامل, لأنه أذا كانت مدخلات المستخدم (NOT PARAMETERIZED)
أو غير مفلترة مثل: أذا أعطينا أجراءين مخزنين
(GET_PASSWORD(userName)) و(GET_USER(userName, password)),
فأن بأمكان المخترق أن يخترق الشيفرة (CODE) في (GET_USER CALL) أذا كان الرقم السري غير مكتوب بشكل صحيح (CORRECTLY ESCAPED) كالتالي:
(GET_USER('admin', "|| GET_PASSWORD('admin') ||"))
لذا فهي ليست أمنة بشكل كامل !.
الحماية من أختراق الجمل المتعددة (PREVENTING MULTI-STATEMENT ATTACK)
كما ذكرنا مسبقا المخاطر المتعلقة باستخدام الجمل المتعددة, فعلى سبيل المثال لو أخذنا موقع إلكتروني يظهر قائمة من السلع لاسم مستخدم
(userName)
معين, فأن جملة الاستعلام ستكون
SELECT*FROM items WHERE userName='$userName';
فمن الممكن ان يقوم المستخدم بأدخال الجملة الأتية:
SELECT*FROM items WHERE userName=''or userName isnotnullor userName='';
أيضا لو لم نستخدم الرموز الخاصة (QUOTES):
SELECT*FROM items WHERE userid=$userid;
فمن الممكن ان يقوم المستخدم بأدخال الجملة الأتية وهي لا تحوي على الرموز الخاصة (QUOTES):
SELECT*FROM items WHERE userid=or userid isnotnullor userid=;
الحل الأنسب لهذه المشكلة هي تعريف المتغير
(userid)
بأن له قيمة عددية فقط, مثل
if (!ctype_digit($userid)){ die("Invalid characters in userid.");}
وهكذا تحل هذه المشكلة.
عدم تفعيل الجمل النصية
من الممكن حل مشكلة اختراق لغة الاستعلام البنيوية في حال ان محرك قاعدة البيانات يدعم خاصية "عدم تفعيل الجمل النصية"
(DISABELING LITERALS)
والتي تعني ان تعمل قاعدة البيانات في وضع
(MODE)
لا يسمح للنصوص والأرقام
(TEXT AND NUMBER LITERALS)
ان يكونوا في جملة الاستعلام, وبالمقابل فقط حائزي المكان مسموح باستخدامهم. لذا جمل بالشكل الأتي
SELECT*FROM items WHERE userid=2;
SELECT*FROM users WHERE name='Smith';
غير مسموح بتنفيذهم في هذا الوضع وسيظهر لنا خطأ
(EXCEPTION),
ويجب علينا كتابتهم هكذا:
SELECT*FROM items WHERE userid=?;
SELECT*FROM users WHERE name=?;
في حال عدم تفعيل الجمل النصية فأن علينا استخدام رموز حائزي المكان والتي يجب استخدامها لجميع مدخلات المستخدمين. حاليا فقط ال
(H2 DATABASE ENGINE)
يدعم خاصية "عدم تفعيل الجمل النصية" وهذه التكنولوجيا جديدة نوعاًً ما لم تسجل لها براءة اختراع بعد.
ببساطة هو طريقة للحصول على ولوج إلى قاعدة البيانات من خلال بعض الثغرات ونقاط الضعف الموجودة في استعلامات التطبيق التي يتصل من خلالها بقاعدة البياناتمثلا استعلام تسجيل الدخول ممكن يكون بالشكل:
select * from users where username='$username' and password='$password'
الثغرة هنا في اسم المستخدم وكلمة المرور انها يتم تبديلها في الاستعلام مباشرةاي لنفرض ان المستخدم أو المخترق وضع التالي مكان كلمة المرور:
' or 1=1
يصبح الاستعلام كما يلي:
select * from users where username='any' and password='' or 1=1;
بالمحصلة سوف يتم تغيير الوظيفة المطلوبة من هذا الاستعلام وإعطاء هذا الدخيل صلاحية عرض البيانات
يمكن تجنب هذه الثغرة باستخدام الباراميترات والإجرائيات المخزنةعلما أنه يوجد بعض الدالات تقوم تقريبا بتأمين النص المدخل لكنها أقل أمان من استخدام الإجرائيات المخزنة والباراميترات
هل تحتاج لمساعدة في كتابة سيرة ذاتية تحتوي على الكلمات الدلالية التي يبحث عنها أصحاب العمل؟