وصف الثغرات شيء ، ولكن محاولة العثور على ثغرة والعمل معها أمر مختلف تمامًا. ولهذه الأغراض يتم إنشاء وتطوير تطبيقات خاصة يتم فيها ترك نقاط الضعف بشكل متعمد. إذا قمت بكتابة طلب البحث "تطبيق ضعيف عمداً" في محرك البحث ، فلن تجد عشرات الروابط.
في هذه السلسلة ، سنبدأ في تحليل الثغرات الأمنية من OWASP Top 10 ، وسأستخدم مثل هذا التطبيق غير المقصود عمداً كأساس للاختبار. في حالتي سيكون OWASP Mutillidae II. هذا ليس الخيار الأفضل ، لكن نقاط الضعف فيه منظمة تمامًا حسب الحاجة للأغراض التعليمية.
امنح يدكلذا ، فإن الضعف الأول هو الحقن. يقدم OWASP Mutillidae II العديد من الخيارات ، وسنبدأ مع أبسط "بيانات استخراج SQLi"> "معلومات المستخدم (SQL)".
أمامنا نافذة المصادقة المعتادة - ما تتفاعل معه يوميًا:
ليس لدينا اسم مستخدم أو كلمة مرور - لا شيء. حسنًا ، فلنقم بالتسجيل في هذا الموقع. سوف أقوم بإنشاء مستخدم باسم أدناهzero273 وكلمة المرور 123:
عظيم! أنشأنا حسابًا ، ويشير النقش الرسمي "تم إدراج صف واحد" إلى أنه تمت إضافة صف ، على ما يبدو إلى الجدول ، لأن تخزين عدد كبير من الحسابات أسهل في نظام إدارة قواعد البيانات.
الآن قم بتسجيل الدخول باستخدام حسابنا الجديد في النظام. ناجح ، عظيم.
عندما نعمل مع صفحة ويب ، يجب أن نتذكر دائمًا أن تفاعلنا لا يقتصر على محتوى الصفحة. هناك أيضًا شريط عنوان ، على سبيل المثال. حيث نلاحظ الكثير من الأشياء المثيرة للاهتمام:
http://127.0.0.1/mutillidae/index.php?page=user-info.php&username=belowzero273&password=123&user-info-php-submit-button=View+Account+Details
على سبيل المثال ، نرى أن كلمة المرور تنتقل بنص واضح. هذا أمر سيئ ، حيث يمكن اعتراض حركة المرور. ولكن ربما ليس مثل هذه الكارثة - سيتم التفاف حركة المرور في TLS.
دعنا نحاول استبدال كلمة المرور مباشرة في السطر ، على سبيل المثال ، هذه القطعة:
username=belowzero273&password=123
على
username=belowzero273&password=12345
كلمة المرور ، بالطبع ، غير صحيحة ، وقد تلقينا الخطأ المقابل: وهذا سيئ. إنه أمر سيئ ، لأنه بمساعدة THC-Hydra ، الذي تحدثت عنه
هنا ، يمكننا التقاط كلمة المرور هذه عن طريق استبدالها في هذا الخط دون أي شكل. ولكن هذا لا يمكن أن يؤدي دائمًا إلى نتيجة إيجابية في فترة زمنية مقبولة.
ليس لدينا الكثير من الوقت ، لذلك دعونا نجرب شيئًا آخر. أضف علامة الفاصلة العليا إلى كلمة المرور غير الصحيحة:
username=belowzero273&password=123
على
username=belowzero273&password=12345'
الآن حصلنا على خطأ كامل:
لا يوجد خطأ في الأخطاء. كيف يمكن تشخيص خلل آخر إذا لم نر ملاحظات من التطبيق؟ ولكن يجب ألا تكون هذه الأخطاء مرئية للمستخدمين والمهاجمين.
الآن نرى أنه في الواقع ، عندما نضغط على الزر "إرسال" في الخلفية ، يتم تنفيذ الطلب التالي:
SELECT * FROM accounts WHERE username='belowzero273' AND password='12345'
تبرز الفواصل العليا متغيرات السلسلة. لا يقوم تطبيق الويب لدينا بتصفية البيانات التي يدخلها المستخدم ، ومع فاصلتنا الإضافية ، انتهكنا الطلب. الآن بعد أن عرفنا كيف يبدو هذا الاستعلام في الخلفية ، نحتاج إلى معرفة كيفية تغييره للحصول على المعلومات التي نحتاجها من قاعدة البيانات.
يرجى ملاحظة أن الطلب يحتوي على ووظيفة ، أي أنه يجب أن يكون كلا المتغيرين صحيحين ، لأن هذا مزيج من تسجيل الدخول وكلمة المرور. منطقي.
دعنا نلقي نظرة سريعة على هذا الاستعلام:
SELECT * FROM accounts WHERE (username='belowzero273' AND password='12345') OR 1='1
لقد أضفنا شرطًا دائمًا: 1 = 1. وسيتم تنفيذ الطلب في حالتين: إما أننا خمنا تركيبة اسم المستخدم وكلمة المرور ، أو 1 = 1. أي أنه سيتم تنفيذها دائمًا.
اتضح أنه يمكن تحديد ما يلي ككلمة مرور:
' or 1='1
لم تعد هناك حاجة للفاصلة العليا في نهاية السطر ، فسيقوم منطق تطبيق الويب بوضعه لنا. بوم! وحصلنا على اختيار من قاعدة البيانات بكل الحسابات:
رائع ، لدينا الآن تسجيلات الدخول وكلمات المرور لكل شخص مسجل في هذا التطبيق. والأسوأ من ذلك ، أن كلمات المرور هنا واضحة.
ما الخطأ في ذلك؟ وحقيقة أن معظم الناس يستخدمون نفس أسماء المستخدمين وكلمات المرور لجميع المواقع. وبعد التسجيل بهذه الطريقة على موقع واحد معرض للخطر ، فقد يفقدون الوصول إلى جميع مواقعهم.
يمكنك أيضًا تجربة هذه الثغرة الأمنية ، على سبيل المثال ، ابحث عن كلمة مرور المسؤول. للقيام بذلك ، استبدل تسجيل الدخول:
admin' or 1='1
أي أننا نبحث عن إدخال في قاعدة البيانات حيث يكون اسم المستخدم admin وكلمة المرور موجودة.
!
لا يتم تخزين كلمات المرور دائمًا بنص واضح ، ولكن هذا لا يعني أن المصادقة تتم بأمان. دعونا نلقي نظرة على المثال الثاني في OWASP Mutillidae II "مصادقة SQLi الالتفافية"> "تسجيل الدخول".
يمكن تجاوز المصادقة عن طريق إنشاء طلب مناظر. في الآونة الأخيرة ، أنشأنا حسابًا تحت الصفر 273 ، والآن دعنا نحدد كمعلومات تسجيل دخول:
' or ('a' = 'a' and username='belowzero273')
هنا نتحقق من الشرط الصحيح الواضح - a = a ، وتسجيل الدخول - belowzero273 ، ونقطع أيضًا جزء الطلب بمساعدة "-".
اضغط على Enter وقم بتسجيل الدخول بنجاح إلى النظام على الرغم من حقيقة أننا لم نحدد كلمة مرورك في أي مكان.
سهل جدايسأل العملاء أحيانًا ، هل من السهل جدًا تجاوز المصادقة على موقعنا؟ عادة أجيب على السؤال بالسؤال: "هل أنت متأكد من أن هذا لم يحدث بالفعل؟" لا تقع الحقن عن طريق الخطأ في أعلى تصنيف OWASP ، لأن نقاط الضعف هذه ، كقاعدة عامة ، لها عواقب وخيمة إذا تم تنفيذها.
في الممارسة العملية ، بالطبع ، كل شيء معقد إلى حد ما أكثر من هذه الأمثلة. ولكن في مثل هذه الأمثلة الأساسية يبدأ فهم المشاكل العميقة في التبلور. سنستمر في المرة القادمة.
اقرأ مدونة المؤلف
على هذا الرابط .