أمن تطبيقات الويب: منهجية عملية لتحليل التطبيق ورسم الخريطة – الجزء الثالث
أمن تطبيقات الويب: منهجية عملية لتحليل التطبيق ورسم الخريطة – الجزء الثالث
في الجزئين السابقين تعرّفنا على المفاهيم الأساسية، وكيف تحدث الثغرات، وكيف يفكر مختبر الاختراق.
الآن ننتقل من النظرية إلى الممارسة.
هذا الجزء مخصص لمن يريد أن يتعلم كيف يبدأ اختبار تطبيق ويب بطريقة منظمة داخل بيئة تدريبية (مثل المختبرات التعليمية أو CTF أو الأنظمة التي تملك تصريحًا باختبارها).
الهدف ليس «البحث العشوائي عن ثغرات»، بل بناء صورة واضحة عن التطبيق قبل أن تبدأ في محاولة كسره.
لماذا رسم الخريطة أهم من اكتشاف الثغرة؟
كثير من المبتدئين يفتحون Burp Suite أو ZAP ويبدأون فورًا في إرسال Payloads.
النتيجة غالبًا تكون: ضياع وقت، وفوات نقاط مهمة، وعدم فهم حقيقي للتطبيق.
المختبر المحترف يفعل العكس:
يجمع المعلومات.
يرسم خريطة كاملة قدر الإمكان.
يفهم التدفق الطبيعي للبيانات والصلاحيات.
ثم يبدأ في الاختبار.
بدون خريطة واضحة، أنت تختبر في الظلام.
المرحلة الأولى: Reconnaissance (جمع المعلومات المسموح بها)
ابدأ دائمًا بما يمكنك رؤيته دون أي تفاعل عدائي:
افتح الموقع كمستخدم عادي.
سجّل حسابًا إن أمكن.
تصفح كل الصفحات المتاحة.
لاحظ الروابط، النماذج، الأزرار، والقوائم.
افتح أدوات المطور في المتصفح (Network + Console + Sources).
راقب الطلبات التي تُرسل عند كل إجراء.
أسئلة مفيدة في هذه المرحلة:
ما النطاق الرئيسي والنطاقات الفرعية؟
هل هناك API منفصل؟
هل التطبيق يستخدم SPA (مثل React أو Vue) أم صفحات تقليدية؟
هل توجد ملفات JavaScript كبيرة تحتوي على مسارات أو مفاتيح؟
هل تظهر معلومات في التعليقات داخل الكود أو في الـ Headers؟
لا تتعجل. هذه المرحلة تبني الأساس.
المرحلة الثانية: Mapping – رسم خريطة التطبيق
الهدف هنا هو تحويل التطبيق من «موقع تشاهده» إلى «نظام تفهمه».
قسّم الخريطة إلى طبقات:
1. الصفحات والواجهات
صفحات عامة
صفحات بعد تسجيل الدخول
صفحات خاصة بكل دور (User / Admin / Moderator…)
2. نقاط الإدخال (Entry Points)
كل مكان يمكن للمستخدم أن يرسل فيه بيانات:
نماذج البحث
نماذج تسجيل الدخول والتسجيل
رفع الملفات
تعديل الملف الشخصي
معلمات الـ URL
Headers
Cookies
Body في طلبات JSON أو XML
3. الوظائف الحساسة
تغيير كلمة المرور
استعادة الحساب
حذف حساب
عمليات الشراء أو التحويل
إدارة الصلاحيات
أي إجراء يؤثر على مستخدمين آخرين
4. آليات المصادقة والجلسات
كيف يتم تسجيل الدخول؟
أين يُخزَّن الـ Session؟
هل يوجد JWT؟
هل الجلسة تنتهي؟
هل يمكن إعادة استخدام الجلسة بعد تسجيل الخروج؟
5. التدفق الطبيعي
ارسم سيناريوهات استخدام حقيقية:
مستخدم جديد يسجل حسابًا ثم يعدّل ملفه الشخصي.
مستخدم يطلب موردًا يخصه.
مستخدم يحاول الوصول إلى مورد يخص مستخدمًا آخر (هذا سيكون مهمًا لاحقًا).
كل هذه المعلومات تُسجَّل. الأفضل أن تكتبها في ملاحظات منظمة أو حتى في رسم بسيط.
المرحلة الثالثة: فهم الصلاحيات قبل اختبارها
من أكبر الأخطاء أن تختبر الصلاحيات قبل أن تفهمها.
قبل أن تبدأ في تجربة IDOR أو Broken Access Control، يجب أن تعرف:
ما الأدوار الموجودة في النظام؟
ما الذي يُسمح لكل دور بفعله؟
هل هناك موارد مرتبطة بملكية مستخدم معين؟
هل التحقق من الصلاحيات يحدث على الخادم أم يعتمد على الواجهة فقط؟
طريقة عملية:
سجّل دخولًا بحساب عادي.
سجّل دخولًا بحساب آخر (إن أمكن).
قارن الطلبات والاستجابات.
لاحظ الفروقات في الـ Headers والـ Cookies والمعرفات.
السؤال الذهبي هنا:
«هل التطبيق يتحقق من أن هذا المستخدم تحديدًا يملك الحق في تنفيذ هذا الإجراء؟»
المرحلة الرابعة: اكتشاف نقاط الدخول الحقيقية
ليس كل إدخال واضحًا.
بعض أهم نقاط الدخول تكون مخفية:
معلمات في الـ URL لا تظهر في الواجهة.
قيم داخل JSON Body.
Headers مخصصة يضيفها التطبيق.
ملفات JavaScript تكشف مسارات API.
طلبات تُرسل تلقائيًا عند تحميل الصفحة.
استخدم Proxy (Burp أو ZAP) لالتقاط كل شيء.
ثم راجع كل طلب وتساءل:
هل هذه القيمة يمكنني التحكم بها؟
أين تذهب هذه القيمة بعد إرسالها؟
هل تصل إلى قاعدة بيانات؟ إلى HTML؟ إلى نظام ملفات؟ إلى خدمة خارجية؟
هذا هو جوهر التفكير الأمني.
المرحلة الخامسة: بناء سيناريوهات الاختبار قبل التنفيذ
بعد رسم الخريطة، لا تبدأ بإرسال Payloads عشوائية.
ابنِ سيناريوهات منطقية:
ماذا يحدث إذا غيّرت معرف المستخدم في الطلب؟
ماذا يحدث إذا أرسلت دورًا مختلفًا؟
ماذا يحدث إذا رفعت ملفًا بامتداد غير متوقع؟
ماذا يحدث إذا أعدت إرسال طلب قديم بعد تسجيل الخروج؟
ماذا يحدث إذا عدّلت قيمة السعر أو الكمية في طلب الشراء؟
كل سيناريو يجب أن يكون مرتبطًا بسؤال واضح عن الأمان.
منهجية مختصرة يمكنك اتباعها في أي مختبر
Recon → فهم السطح الظاهر.
Mapping → رسم الصفحات + الوظائف + نقاط الإدخال.
Authentication & Session → فهم كيف يتعرف التطبيق عليك.
Authorization → اختبار الحدود بين المستخدمين والأدوار.
Input Handling → كيف يتعامل التطبيق مع البيانات التي ترسلها.
Business Logic → هل القواعد التي يفترض أن تحكم التطبيق موجودة فعليًا على الخادم؟
Configuration → الإعدادات والرؤوس والمعلومات المكشوفة.
Documentation → توثيق ما وجدته وكيف يؤثر.
نصيحة مهمة
الأدوات مساعدة، لكنها لا تفكر نيابة عنك.
Burp Suite يعطيك الرؤية، لكن الفهم يأتي منك.
كلما أصبحت أفضل في قراءة الطلبات والاستجابات، وكلما أصبحت أدق في رسم الخريطة، كلما أصبحت أقدر على اكتشاف المشاكل الحقيقية، حتى لو لم تكن من الثغرات الشهيرة.جملة الدعوة للتفاعل (ضعناها في نهاية المقال):
إذا استفدت من المقال، شاركني رأيك في التعليقات، وأخبرني هل تفضل أن يكون الجزء القادم تطبيقيًا على مختبر حقيقي؟
تعليقات