العثور على ثغرات تطبيق الويب

حالة استخدام

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

الأهداف

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

العرض

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

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

أهداف التمرن

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

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

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

تنظيم اختبارك

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

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

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

إعداد التقارير

أخيرًا وكي يتمكّن أي شخص من الاستفادة من عملك الشاق ستحتاج إلى توثيق الثغرات التي تجدها، حيث إنه بشكل عام ستقوم بفحص موقع شخص آخر وستُنتج نوعًا من التقارير سواء كانت رسمية أو غير رسمية. وبغض النظر يجب أن تكون بعض الأهداف الأساسية أو التقرير هي إيصال المعلومات التالية:

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

عادةً ما تحتوي التقارير على قسم تمهيدي يتحدث عما تم اختباره وما لم يتم اختباره متبوعًا بقسم آخر يحتوي تفاصيل كل ثغرة عُثر عليها، ودعونا نتعمق في كل قسم.

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

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

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

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

• الموقع: عنوان موقع الويب ومعامله أو مجرد عنوان موقع الويب فقط و/أو سطر تعليمات برمجية (في حال كانت معروفة)، مما سيساعد المطورين في العثور على التعليمات البرمجية التي تحتوي على الثغرة. لاحظ أن بعض الثغرات الأمنية قد تكون موجودة في أماكن متعددة وفي هذه الحالة عادة ما يكون من الجيد توثيق مواقع متعددة وفي بعض الحالات قد توجد ثغرة أمنية في جميع أنحاء الموقع، بينما في حالات أخرى قد يكون موجودًا في أماكن كثيرة جدًا إلى حد لا يسمح بالتوثيق ولكن ليس في كل مكان. على أي حال، يُعدّ الهدف هو الوضوح حيث يجب على القارئ أن يفهم أي من الحالات المذكورة أعلاه موجودة.
• كيفية التسبب بحدوث الثغرة: غالبًا ما يشار إليها باسم “خطوات التكرار” وهي وصف لكيفية التسبب بحدوث الثغرة، وهو أمر لا يقدر بثمن لفرق التطوير التي تحاول إصلاح الثغرة. في بعض الحالات، يمكن أن يكون هذا بسيطًا مثل مجرد عنوان موقع الويب (على سبيل المثال، شيء مثل “قم بزيارة http://victim.com/search?q=<script>alert(‘xss’)</script>)، وفي حالات أخرى قد تكون هناك حاجة إلى مراحل متعددة من الإعداد. من الناحية المثالية يجب أن تكون خطوات التكرار واضحة ومن السهل تكرارها.
• تصنيف المخاطر: تصنيفات مخاطر ذاتية إلى حد ما وغالبًا ما تتطلب بيانات غير متاحة بسهولة للشخص الذي يُجري الاختبار (مثل الأهمية النسبية لموقع الويب هذا بالنسبة لمالكه)، لكن يجب أن تكون متسقة داخليًا على الأقل في التقرير، فعادة ما يستخدم مقياس تقييم مثل الوارد أدناه:
• الحالات الحرجة: الثغرات شديدة الخطورة التي يمكن أن تؤدي إلى اختراق التطبيق بطريقة سهلة، مثل تنفيذ التعليمات البرمجية عن بُعد أو حقن لغة الاستعلامات البنيوية والتي تسمح باستغلالها من قبل أي شخص عبر الإنترنت. إذا كان أول ما يجول خاطرك عند العثور على ثغرة أمنية هي “كيف من المعقول أن هذا التطبيق لا يُستغل في تعدين البيتكوين أو إرسال رسائل غير مرغوب فيها؟” فمن الأغلب أنه خطر حرج.
• الحالات عالية الخطورة: ثغرات شديدة تؤدي إلى اختراق أقل شمولية و/أو يصعب استغلاله، ومن الأمثلة على ذلك حقن لغة الاستعلامات البنيوية الذي لا يمكن استغلاله إلا من قبل المستخدمين الداخليين، أو معظم ثغرات التخويل أو البرمجة النصية عبر المواقع التي يمكن تحويلها إلى ديدان. إذا كان أول ما يجول خاطرك عند العثور على ثغرة هي إخبار مالك الموقع على الفور فمن المحتمل أن تكون عالية الخطورة.
• الحالات متوسطة الخطورة: ثغرات لن يؤدي استغلالها إلا إلى اختراق جزئي للتطبيق أو يكون لها تأثير كبير ولكن من الصعب جدًا استغلالها (مثل هجوم التوقيت الذي يتطلب عدة مليارات من الطلبات)، وتندرج تحت هذا التصنيف معظم ثغرات البرمجة النصية عبر المواقع وتزييف طلب المواقع المشتركة، والكشف الجزئي عن المعلومات (مثل مشكلات التخويل البسيطة أو معظم حالات كشف التعليمات البرمجية المصدر)، وعادة ما تكون هذه ثغرات تحتاج الإصلاح ولكن ليست حالة طارئة.
• الحالات منخفضة الخطورة: للثغرات تأثير على التطبيق ولكن هذا التأثير طفيف للغاية، وعادةً ما تكون مثل الإفصاحات الطفيفة جدًا عن المعلومات أو المشكلات التي تجعل استغلال ثغرات الأخرى أسهل إلى حد ما (مثل الافتقار حد على المعدلات) أو عدم الامتثال لأفضل الممارسات التي ليس لها تأثير حقيقي.
• الحالات المعلوماتية: تشمل هذه الثغرات كلًا من الثغرات الأمنية التي لا يمكن استغلالها في الواقع ولكن من المحتمل أن تصبح مشاكل في المستقبل والأخطاء الوظيفية التي ليس لها أي تأثير أمني أو غيرها من المسائل غير الأمنية.

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

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

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

• بيشوب فوكس (Bishop Fox) - ونستون برايفيسي (Winston Privacy)
• كيور 53 (Cure53) - ون باسوورد (1Password)
• دوين سيك (DoyenSec) - غرافيتي بلاتفورم (Gravity Platform)
• آي سيك (iSEC) - ب إتش ب ماي آدمن (phpMyAdmin)

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

الممارسة

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

1. ثبّت جوس شوب (أسهل طريقة هي باستخدام داكر)
2. يحتوي جوس شوب بشكل افتراضي على ثغرات أمنية خطيرة غير مفعّلة، وهي أهم ثغرات يجب العثور عليها. ستحتاج إلى تغيير التكوين لضبط خيار safetyOverride بحيث يصبح true وعند قيامك بذلك تأكد أيضًا من تضمين جميع علامات التكوين في quiet.yml.
3. أعد بيئة الاختبار خاصتك:

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

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

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

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

اختبار مهارة

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

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

موارد التعلّم