أساسيات القرصنة على الويب wep applications الجزء السادس xss

 

تقسم هذه الدورة كل موضوع من مواضيع OWASP وتتضمن تفاصيل حول ماهية  الثغرة الأمنية  وكيف تحدث وكيف يمكنك استغلالها. ستضع النظرية موضع التنفيذ من خلال استكمال التحديات الداعمة.

• حقنة
• المصادقة معطلة
• التعرض للبيانات الحساسة
• وحدة XML الخارجية
• كسر التحكم في الوصول
• خطأ في التكوين الأمني
• عبر موقع البرمجة
• أنا nsecure إلغاء التسلسل
• المكونات ذات الثغرات الأمنية المعروفة
• التسجيل غير الكافي والمراقبة

تم تصميم الدورة للمبتدئين ولا تفترض أي معرفة سابقة بالأمان.

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

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

إذا كان المهاجم قادرًا على تمرير الإدخال الذي تم تفسيره بشكل صحيح بنجاح ، فسيكون قادرًا على القيام بما يلي:

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

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

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

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

يحدث Command Injection عندما يقوم كود من جانب الخادم (مثل PHP ) في تطبيق ويب بإجراء مكالمة نظام على جهاز الاستضافة. إنها ثغرة في الويب تسمح للمهاجم بالاستفادة من استدعاء النظام لتنفيذ أوامر نظام التشغيل على الخادم. في بعض الأحيان ، لا ينتهي هذا دائمًا بشيء ضار ، مثل whoami  قراءة الملفات أو مجرد قراءتها. هذا ليس سيئا للغاية. لكن الشيء المتعلق بحقن الأوامر هو أنه يفتح العديد من الخيارات للمهاجم. أسوأ شيء يمكن أن يفعلوه هو إنتاج غلاف عكسي ليصبح المستخدم الذي يعمل خادم الويب به. كل ما هو بسيط  ;nc -e /bin/bash هو كل ما هو مطلوب وهم يمتلكون الخادم الخاص بك ؛ بعض المتغيرات من netcat لا تدعم الخيار -e. يمكنك استخدام قائمة من  هؤلاء قذائف عكسية كبديل. 

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

ما هو حقن الأمر النشط؟

يحدث إدخال الأمر Blind عندما لا يقوم أمر النظام الذي يتم إجراؤه على الخادم بإرجاع الاستجابة إلى المستخدم في مستند HTML. سيعيد إدخال الأمر النشط الرد إلى المستخدم. يمكن جعله مرئيًا من خلال العديد من عناصر HTML. 

لنفكر في سيناريو: بدأت EvilCorp في التطوير على قذيفة قائمة على الويب لكنها تركتها معرضة للإنترنت عن طريق الخطأ. لم يتم الانتهاء منه بعد ولكنه يحتوي على نفس الثغرة الأمنية لحقن الأوامر كما كان من قبل! لكن هذه المرة ، يمكن رؤية الاستجابة من مكالمة النظام على الصفحة! لن يتعلموا أبدًا!

تمامًا كما في السابق ، دعنا نلقي نظرة على نموذج التعليمات البرمجية من evilshell.php ونستعرض ما يفعله ولماذا يجعله حقناً نشطًا للأوامر. انظر إذا كنت تستطيع معرفة ذلك. سوف أتطرق إليها  تمامًا كما كان من قبل.

EvilShell (evilshell.php) 

في pseudocode ، يقوم المقتطف  بما يلي:

1. التحقق من تعيين المعلمة "commandString"

2. إذا كان الأمر كذلك ، فإن المتغير  $command_string يحصل على ما تم تمريره إلى حقل الإدخال

3. ينتقل البرنامج بعد ذلك إلى كتلة المحاولة لتنفيذ الوظيفة  passthru($command_string). يمكنك قراءة المستندات على  passthru() موقع  PHP على الويب ، ولكن بشكل عام ، يتم تنفيذ ما يتم إدخاله في الإدخال ثم إعادة الإخراج مباشرة إلى المتصفح .

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

طرق الكشف عن حقن الأوامر النشط

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

أوامر للمحاولة

Linux

• whoami
• id
• ifconfig/ip addr
• uname -a
• ps -ef

Windows

• whoami
• ver
• ipconfig
• tasklist
• netstat -an

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

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

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

يمكن أن يكون هناك تخفيف مختلف لآليات المصادقة المعطلة اعتمادًا على الخلل الدقيق:

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

في هذا المثال ، سننظر في عيب منطقي داخل آلية المصادقة.

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

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

لرؤية هذا في العمل ، انتقل إلى http: // MACHINE_IP: 8888  وحاول تسجيل اسم مستخدم  يا عزيزي ، سترى أن المستخدم موجود بالفعل ، ثم حاول تسجيل مستخدم  "  darren "  وستلاحظ أنك الآن قمت بتسجيل الدخول وستتمكن من رؤية المحتوى الموجود فقط في حساب Darren والذي في حالتنا هو العلامة التي تحتاج إلى استردادها.

عندما يكشف تطبيق ويب عن غير قصد عن بيانات حساسة ، فإننا نشير إليها باسم "التعرض للبيانات الحساسة". غالبًا ما تكون هذه البيانات مرتبطة مباشرة بالعملاء (مثل الأسماء وتواريخ الميلاد والمعلومات المالية وما إلى ذلك) ، ولكنها قد تكون أيضًا معلومات تقنية أكثر ، مثل أسماء المستخدمين وكلمات المرور. في المستويات الأكثر تعقيدًا ، غالبًا ما يتضمن ذلك تقنيات مثل "Man in The Middle Attack" ، حيث يفرض المهاجم اتصالات المستخدم من خلال جهاز يتحكم فيه ، ثم يستفيد من ضعف التشفير على أي بيانات مرسلة للوصول إلى المعلومات التي تم اعتراضها (إذا تم تشفير البيانات في المقام الأول ...). بالطبع ، العديد من الأمثلة أبسط بكثير ، ويمكن العثور على نقاط الضعف في تطبيقات الويب التي يمكن استغلالها دون أي معرفة متقدمة بالشبكات. في الواقع ، في بعض الحالات ،

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

الطريقة الأكثر شيوعًا لتخزين كمية كبيرة من البيانات بتنسيق يمكن الوصول إليه بسهولة من العديد من المواقع في وقت واحد هي في قاعدة البيانات. من الواضح أن هذا مثالي لشيء مثل تطبيق الويب ، حيث قد يكون هناك العديد من المستخدمين الذين يتفاعلون مع موقع الويب في أي وقت. عادة ما تتبع محركات قواعد البيانات  صيغة S tructured  Q uery  L anguage (SQL) ؛ ومع ذلك ، تزداد شعبية التنسيقات البديلة (مثل NoSQL).

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

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

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

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

لنفترض أننا نجحنا في تنزيل قاعدة بيانات:

يمكننا أن نرى أن هناك قاعدة بيانات SQlite في المجلد الحالي.

للوصول إليه نستخدم  sqlite3 <database-name>:

من هنا يمكننا رؤية الجداول في قاعدة البيانات باستخدام  .tables الأمر:

في هذه المرحلة ، يمكننا تفريغ جميع البيانات من الجدول ، لكننا لن نعرف بالضرورة ما يعنيه كل عمود ما لم ننظر إلى معلومات الجدول. لنستخدم أولاً  PRAGMA table_info(customers); لرؤية معلومات الجدول ، ثم سنستخدمها  SELECT * FROM customers; لتفريغ المعلومات من الجدول:

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

0|Joy Paulson|4916 9012 2231 7905|5f4dcc3b5aa765d61d8327deb882cf99

 

لدينا CUSTID (0) ، و custName (Joy Paulson) ، و CreditCard (4916 9012 2231 7905) وتجزئة كلمة المرور (5f4dcc3b5aa765d61d8327deb882cf99).

في المهمة التالية سننظر في كسر هذا التجزئة.

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

عندما يتعلق الأمر بتكسير التجزئة ، تأتي Kali مثبتة مسبقًا بأدوات مختلفة - إذا كنت تعرف كيفية استخدامها ، فلا تتردد في القيام بذلك ؛ ومع ذلك ، فهم خارج نطاق هذه المادة.

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

عندما ننتقل إلى موقع الويب ، نلتقي بالواجهة التالية:

لنحاول لصق تجزئة كلمة المرور لـ Joy Paulson التي وجدناها في المهمة السابقة ( 5f4dcc3b5aa765d61d8327deb882cf99). نقوم بحل Captcha ، ثم نضغط على زر "Crack Hashes":

نرى أنه تم كسر التجزئة بنجاح ، وأن كلمة مرور المستخدم كانت "كلمة مرور" - ما مدى أمانها!

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

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

(قروض لموقع acunetix.com للصورة)

هجوم XML External Entity (XXE) هو ثغرة أمنية تسيء استخدام ميزات موزعي / بيانات XML. غالبًا ما يسمح للمهاجم بالتفاعل مع أي واجهة خلفية أو أنظمة خارجية يمكن للتطبيق نفسه الوصول إليها ويمكن أن يسمح للمهاجم بقراءة الملف الموجود على هذا النظام. يمكنهم أيضًا التسبب في هجوم رفض الخدمة (DoS) أو يمكنهم استخدام XXE لتنفيذ طلب تزوير من جانب الخادم (SSRF) لتحفيز تطبيق الويب على تقديم طلبات إلى تطبيقات أخرى. قد يقوم XXE بتمكين فحص المنفذ ويؤدي إلى تنفيذ التعليمات البرمجية عن بُعد.

هناك نوعان من هجمات XXE: داخل النطاق وخارج النطاق (OOB-XXE).

1) هجوم XXE داخل النطاق هو الهجوم الذي يمكن أن يتلقى فيه المهاجم استجابة فورية لحمولة XXE.

2) هجمات XXE خارج النطاق (وتسمى أيضًا XXE الأعمى) ، لا توجد استجابة فورية من تطبيق الويب ويجب على المهاجم أن يعكس ناتج حمولة XXE الخاصة به إلى ملف آخر أو خادم خاص به.