تخطي إلى المحتوى

حالة استخدام

يُعدّ الموضوع الفرعي 5 متطلبًا مسبقًا يجب إكماله قبل هذا الموضوع ونشجع المتعلمين بشدة على قراءته بدقة قبل المتابعة.

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

بمجرد معرفة أساسيات العثور على ثغرات في مواقع الويب، سيُعلّمك هذا الموضوع الفرعي عملية للعثور على هذه الثغرات بسرعة وكفاءة أكبر.

الأهداف

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


العرض

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

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

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

الاستراتيجية 1: عملية الفحص

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

البدء

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

  • هل يمكن للمستخدمين تحرير منشورات بعضهم البعض؟
  • هل يمكن للمستخدمين رؤية الرسائل الخاصة التي تخص بعضهم البعض؟
  • هل يمكن للمستخدمين من غير المديرين أو المشرفين أداء وظائف الإدارة؟
  • هل يمكن للمستخدمين أو المديرين غير المشرفين أداء وظائف الإشراف؟

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

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

A big table which lists every item on a webpage that can be accessed by a user, along with its URL and a checklist for who can access itunauthenticated users, particular authenticated users, moderators, or admins

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

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

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

اختبار لكل موقع

تنطبق أجزاء معينة من المنهجية على الموقع بأكمله أو على بعض الأماكن منه، حيث يتمتع كل خادم ويب بتكوين مختلف وتحتوي معظم مواقع الويب على خادم واحد أو عدة خوادم منطقية (e.g. www.example.com, api.example.com, static.example.com). تحتوي معظم المواقع على قسم واحد (أو ربما قسمين) لتسجيل الدخول/تسجيل حساب/إدارة الحساب وآليات إدارة الجلسة، وعليك إجراء هذه الاختبارات كخطوة تالية. سيتيح لك القيام بذلك أن تشعر بأنك تحقق نتيجة لأنك ستستكمل أقسام منهجية متعددة بسرعة وسيمنحك فرصة لفهم الأسس الهيكلية للموقع. خلال إجراء هذه الاختبارات قد تجد صفحات ويب إضافية فاتتك في المرة الأولى، ولا مشكلة في حال حصل ذلك ولكن تأكد من إضافتها إلى جدول بياناتك!

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

اختبار لكل صفحة

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

A screenshot of a similar table to the one above except that there are not more columns which allow the person filling it in to check boxes for various authorization, authentication, XSS, and other vulnerabilities they might encounter

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

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

الاستراتيجية 2: اختبارات الإطار الزمني

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

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

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

الاستراتيجية 3: التوثيق أثناء تقدمك

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

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

يجب أن تُهيئك هذه الاستراتيجيات للنجاح في اختبار مواقع الويب، وسنضعها موضع التنفيذ في القسم الفرعي التالي من هذا الموضوع الفرعي.

التفكير في الثغرات من خلال عدسة نموذج الربط البيني للأنظمة المفتوحة

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

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

LayerName
layer 1APPLICATION
layer 2PRESENTATION
layer 3SESSION
layer 4TRANSPORT
layer 5NETWORK
layer 6DATA LINK
layer 7PHYSICAL

يتكون نموذج الربط البيني للأنظمة المفتوحة من سبع طبقات:

  1. التطبيق: يُوفر قدرات الربط الشبكي لبرامج الكمبيوتر مما يسهل نقل البيانات بين التطبيقات، وثم تُمرر البيانات الواردة في هذه الطبقة إلى طبقة التقديم.
  2. التقديم: تتلقى البيانات من طبقة التطبيق وغالبًا ما تكون بصيغة تخص التطبيق، ثم توحد تنسيق البيانات وتتعامل مع مهام مثل التشفير والضغط قبل تمريرها إلى طبقة الجلسة.
  3. الجلسة: تحاول إنشاء اتصال مع كمبيوتر آخر عبر الشبكة والحفاظ عليه، حيث تُدير جلسات الاتصال وتُزامن تبادل البيانات بين المضيف وأجهزة الكمبيوتر البعيدة.
  4. النقل: تحدد بروتوكول الإرسال (بروتوكول تحكم الإرسال أو بروتوكول مخطط بيانات المستخدم) وتُقسم البيانات إلى شرائح أو مخططات بيانات يمكن إدارتها، حيث يوفر بروتوكول تحكم الإرسال إرسالًا موثوقًا قائمًا حسب الاتصال بينما يعطي بروتوكول مخطط بيانات المستخدم الأولوية للسرعة.
  5. الشبكة: تُحدد وجهة نقل البيانات باستخدام العناوين المنطقية (على سبيل المثال، عناوين بروتوكول الإنترنت) لتحديد أفضل مسار عبر الشبكة، وتتضمن تنسيقات العنونة المنطقية الشائعة بروتوكول الإنترنت الإصدار 4.
  6. رابط البيانات: تُركز على المعالجة الفعلية عن طريق إضافة عنوان وحدة التحكم في الوصول إلى الوسائط (MAC أو Media Access Control) لنقطة النهاية المستقبلة لحزمة الإرسال وتضمن أيضًا سلامة نقل البيانات وتُحضر البيانات لإرسالها.
  7. الفعلية: يتعامل مع جوانب نقل البيانات على مستوى الأجهزة ويحول البيانات الثنائية إلى إشارات لإرسالها عبر الشبكة، وهي مسؤولة عن إرسال واستقبال النبضات الكهربائية التي تُمثل نقل البيانات.

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

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

الممارسة

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

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

اختبار مهارة

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

إذا لم يكن لديك مرشدًا فيمكنك أن تراجع نفسك باستخدام القائمة أعلاه.