كيف يسيطر المخترقون على مواقع الويب بحقن SQL و DDoS

حتى لو كنت قد اتبعت بشكل فضفاض فقط أحداث مجموعات الهاكر Anonymous و LulzSec ، فربما سمعت عن مواقع الويب والخدمات التي يتم اختراقها ، مثل قرصنة سوني الشهيرة. هل سبق لك أن تساءلت كيف يفعلون ذلك?

هناك عدد من الأدوات والتقنيات التي تستخدمها هذه المجموعات ، وبينما لا نحاول أن نوفر لك دليلاً للقيام بذلك بنفسك ، من المفيد فهم ما يحدث. اثنين من الهجمات التي تسمعها باستمرار باستخدامها هي "(الموزعة) الحرمان من الخدمة" (DDoS) و "SQL Injections" (SQLI). إليكم كيف يعملون.

الصورة بواسطة XKCD

الحرمان من الخدمة الهجوم

ما هذا?

يحدث "رفض الخدمة" (يطلق عليه أحيانًا اسم "رفض الخدمة الموزعة" أو DDoS) عندما يتلقى نظام ، في هذه الحالة خادم ويب ، العديد من الطلبات في وقت واحد بحيث يتم تحميل موارد الخادم بشكل زائد بحيث يتم قفل النظام ببساطة ويغلق. الهدف والنتيجة لنجاح هجوم DDoS هو عدم توفر مواقع الويب على الخادم الهدف لطلبات حركة المرور المشروعة.

كيف يعمل?

قد يكون أفضل تفسير لوجستيات هجوم DDoS على سبيل المثال.

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

يعمل هجوم DDoS على خادم ويب بالطريقة نفسها تمامًا. نظرًا لعدم وجود طريقة لمعرفة ما هي مصادر الزيارات من الطلبات المشروعة مقابل المهاجمين إلى أن يقوم خادم الويب بمعالجة الطلب ، يكون هذا النوع من الهجوم فعّالًا جدًا.

تنفيذ الهجوم

نظرًا لطبيعة "القوة الغاشمة" لهجوم DDoS ، يجب أن يكون لديك الكثير من أجهزة الكمبيوتر كلها منسقة للهجوم في نفس الوقت. وبالرجوع إلى مثال مركز الاتصال لدينا ، فإن ذلك يتطلب من جميع المهاجمين معرفة الاتصال بهم في الساعة 9 صباحًا واستدعاء فعليًا في ذلك الوقت. في حين أن هذا المبدأ سيعمل بالتأكيد عندما يتعلق الأمر بمهاجمة خادم ويب ، فإنه يصبح أسهل بكثير عندما يتم استخدام أجهزة zombie ، بدلاً من أجهزة الكمبيوتر المأهولة الفعلية.

كما تعلمون على الأرجح ، هناك الكثير من أنواع البرامج الضارة وأحصنة طروادة التي ، في حال وجودها على نظامك ، تكمن في حالة نائمة وفي بعض الأحيان "هاتف المنزل" للحصول على التعليمات. يمكن أن يكون أحد هذه التعليمات ، على سبيل المثال ، إرسال طلبات متكررة إلى خادم الويب الخاص بشركة X في الساعة 9 صباحًا. لذلك ، مع تحديث واحد لموقع المنزل الخاص بالبرامج الضارة ، يمكن لمهاجم واحد أن ينسق على الفور مئات الآلاف من أجهزة الكمبيوتر المخترقة لتنفيذ هجوم DDoS كبير.

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

هجوم حقن SQL

ما هذا?

إن هجوم "SQL injection" (SQLI) هو استغلال يستفيد من تقنيات تطوير الويب الضعيفة ، ويقترن عادة بأمن قاعدة البيانات الخاطئ. يمكن أن تتراوح نتيجة هجوم ناجح من انتحال شخصية حساب مستخدم إلى تسوية كاملة من قاعدة البيانات أو الخادم المعني. على عكس هجوم DDoS ، يمكن منع هجوم SQLI بشكل كامل وسهل إذا تم برمجة تطبيق الويب بشكل مناسب.

تنفيذ الهجوم

كلما قمت بتسجيل الدخول إلى موقع ويب وأدخل اسم المستخدم وكلمة المرور ، من أجل اختبار بيانات الاعتماد الخاصة بك ، قد يقوم تطبيق الويب بتشغيل استعلام كالتالي:

SELECT UserID FROM Users WHERE UserName = "myuser" AND Password = "mypass"؛

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

لذلك يجب أن يتطابق الجمع بين اسم المستخدم الذي تم إدخاله (myuser) وكلمة المرور (mypass) مع إدخال في جدول المستخدمين حتى يتم إرجاع UserID. في حالة عدم وجود تطابق ، لا يتم إرجاع UserID حتى تكون بيانات اعتماد تسجيل الدخول غير صالحة. في حين أن تطبيق معين قد يختلف ، فإن الميكانيكا هي معايير قياسية.

لذا دعونا الآن نلقي نظرة على استعلام مصادقة النموذج الذي يمكننا استبدال القيم التي يدخلها المستخدم على نموذج الويب:

SELECT UserID FROM Users WHERE UserName = "[user]" AND Password = "[pass]"

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

على سبيل المثال ، لنفترض أن "myuser'-" تم إدخاله في حقل اسم المستخدم و "passpass" يتم إدخاله في كلمة المرور. باستخدام الاستبدال البسيط في طلب بحث القالب ، سنحصل على هذا:

SELECT UserID FROM Users WHERE UserName = "myuser" - 'AND Password = "wrongpass"

مفتاح هذا البيان هو تضمين الشرطين (-). هذا هو الرمز المميز لبدء التعليق لعبارات SQL ، لذلك سيتم تجاهل أي شيء يظهر بعد الشرطين (ضمنا). أساسا ، يتم تنفيذ الاستعلام أعلاه من قبل قاعدة البيانات على النحو التالي:

SELECT UserID FROM Users WHERE UserName = "myuser"

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

ما الضرر الذي يمكن القيام به?

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

استنادًا إلى المثال أعلاه ، يمكنك أن ترى ذلك عن طريق الدخول ، على سبيل المثال, "youruser" - "،" admin "-" أو أي اسم مستخدم آخر ، يمكننا تسجيل الدخول على الفور إلى الموقع باسم هذا المستخدم دون معرفة كلمة المرور. بمجرد أن نكون في النظام لا نعرف أننا لسنا بالفعل هذا المستخدم لذلك لدينا حق الوصول الكامل إلى الحساب المعني. لن توفر أذونات قواعد البيانات شبكة أمان لهذا ، لأنه عادةً ما يكون موقع الويب على الأقل لديه حق الوصول للقراءة / الكتابة إلى قاعدة البيانات الخاصة به.

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

لتوضيح الضرر الذي يمكن القيام به في هذه الحالة ، سنستخدم المثال المذكور في الكوميكس أعلاه عن طريق إدخال ما يلي في حقل اسم المستخدم: "Robert" ؛ DROP TABLE Users ؛ - ". بعد استبدال بسيط يصبح استعلام المصادقة:

حدد UserID المستخدم من المستخدمين WHERE UserName = "Robert"؛ DROP TABLE Users ؛ - 'AND Password = "wrongpass"

ملاحظة: يتم استخدام الفاصلة المنقوطة في استعلام SQL للإشارة إلى نهاية عبارة معينة وبداية عبارة جديدة.

الذي يتم تنفيذه بواسطة قاعدة البيانات على النحو التالي:

حدد UserID المستخدم من المستخدمين WHERE UserName = "Robert"

DROP TABLE Users

هكذا فقط ، استخدمنا هجوم SQLI لحذف جدول المستخدمين بالكامل.

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

منع هجوم حقن SQL

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

يتم إحباط هجوم SQLI بسهولة مما يسمى تطهير (أو الهروب) المدخلات الخاصة بك. عملية التطهير هي في الواقع تافهة تماماً حيث أن كل ما تقوم به هو التعامل مع أي حرف مفرد مضمن (') بشكل مناسب بحيث لا يمكن استخدامه لإنهاء سلسلة داخل عبارة SQL قبل الأوان..

على سبيل المثال ، إذا أردت البحث عن "O'neil" في قاعدة بيانات ، فلا يمكنك استخدام استبدال بسيط لأن الاقتباس المفرد بعد O سيؤدي إلى إنهاء السلسلة قبل الأوان. بدلاً من ذلك يمكنك تطهيره باستخدام حرف الهروب الخاص بكل قاعدة بيانات. لنفترض أن حرف الهروب الخاص بعلامة اقتباس مفردة مضمنة هو وضع كل عرض تسعير مسبق بكلمة \ رمز. لذلك "أونيل" سيتم تطهيره كـ "O \ 'نيل".

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

myuser "-- / تمريرة خاطئة:

SELECT UserID FROM Users WHERE UserName = "myuser \" - 'AND Password = "wrongpass"

لأن الاقتباس المفرد بعد myuser يتم الإفلات منه (بمعنى أنه يعتبر جزءًا من القيمة الهدف) ، فإن قاعدة البيانات سوف تبحث حرفيا عن UserName "myuser" - ". بالإضافة إلى ذلك ، نظرًا لأنه يتم تضمين الشرط داخل قيمة السلسلة وليس عبارة SQL نفسها ، فسيتم اعتبارها جزءًا من القيمة الهدف بدلاً من تفسيرها كتعليق SQL.

روبرت '؛ DROP TABLE Users-- / تمريرة خاطئة:

حدد UserID المستخدم من المستخدمين WHERE UserName = "Robert \"؛ DROP TABLE Users ؛ - 'AND Password = "wrongpass"

من خلال الهروب من الاقتباس المفرد بعد روبرت ، يتم تضمين كل من الفاصلة المنقوطة والشرطات في سلسلة بحث UserName ، لذلك ستبحث قاعدة البيانات فعليًا عن "Robert" ؛ DROP TABLE Users ؛ - " بدلا من تنفيذ الجدول حذف.

باختصار

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

لا يمكن تجنب أنواع معينة من الهجمات ، مثل DDoS ، بينما لا يمكن تجنب أنواع أخرى ، مثل SQLI. ومع ذلك ، فإن الأضرار التي يمكن أن تحدث من خلال هذه الأنواع من الهجمات يمكن أن تتراوح في أي مكان من إزعاج إلى كارثة اعتمادا على الاحتياطات المتخذة.