الوكيل الاعتراضي

لماذا يهم

كثير من عيوب الويب الخطيرة يكمن فيما يثق به الخادم. فإذا افترض الخادم أن المتصفح لن يرسل إلا معرّفات طلبات شراء تخصّ المستخدم المسجَّل دخوله، فإن تغيير ذلك المعرّف في الوكيل قد يكشف خلال دقائق خلل التحكم في الوصول (Broken Access Control)، وهو الفئة A01 في OWASP Top 10:2025 التي عرفتها في الدرس السابق. أما الزرّ المعطَّل والحقل المخفي والتحقق في جانب العميل فهي مجرد اقتراحات للمتصفح؛ والوكيل يتيح لك اختبار الخادم، وهناك يجب أن يصمد الأمان.

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

أين يقع الوكيل، وكيف تهيّئه بأمان

يستمع الوكيل على عنوان محلي، مثل 127.0.0.1:8080. تُوجّه المتصفح إليه، فيصبح كل طلب يسير من المتصفح إلى الوكيل إلى الخادم، وتعود كل استجابة بالطريقة نفسها. وبخلاف لوحة الشبكة (Network) في أدوات المطوّر، التي تسجّل ما فعله تبويب واحد، يقف الوكيل في مسار الرسالة ويستطيع إيقافها قبل أن يراها الخادم.

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

جرّبها: فاحص طلبات HTTP

السجل، والاعتراض والتعديل، وإعادة التشغيل

يسرد السجل (تبويب History في ZAP؛ وتسمّيه أدوات أخرى HTTP history) كل طلب واستجابة، مع مرشّحات مثل الطريقة ورمز الحالة ونمط عنوان (URL) يطابق مضيفاً واحداً، لتجد الاستدعاء الذي تحتاجه بين المئات. والاعتراض والتعديل (Intercept and Modify) يوقف الطلب عند الوكيل: فتُحرّر ترويسةً أو معاملاً أو المتن، ثم تدعه يُكمِل، فيتلقّى الخادم نسختك لا نسخة المتصفح.

وإعادة التشغيل (Replay) ترسل طلباً من السجل مجدداً بقيمة واحدة مغيَّرة لتقارن الاستجابات؛ وفي ZAP تنقر عليه بالزر الأيمن وتختار «Open/Resend with Request Editor». وإعادة التشغيل تحوّل «الزرّ معطَّل» إلى حقيقة عن الخادم. وتغطي ثلاث إعادات تشغيل معظم الفحوص الأولى:

• معرّف مغيَّر: أبقِ جلستك واطلب طلب شراء أو ملفاً شخصياً يخصّ مستخدماً آخر. يجب أن يرفض الخادم.
• دور مغيَّر: أعد إرسال طلب لا يجوز إلا للمسؤول (admin) بجلسة مستخدم عادي، أو غيّر حقل role من user إلى admin عند تحديث حساب الاختبار الخاص بك. يجب أن يرفض الخادم التغيير أو يتجاهله.
• قيمة جلسة مغيَّرة: احذف ملف تعريف ارتباط الجلسة، أو أعد استعمال واحد من جلسة سجّلت الخروج منها. يجب أن يجيب الخادم بـ401 Unauthorized أو يوجّهك إلى تسجيل الدخول، لا أن يعيد البيانات أبداً.

جرّبها: محلّل ترويسات HTTP جرّبها: مختبِر مصادقة API

الفحص السلبي: دليل أولي لا حُكم

أثناء مرور حركة المرور عبره، يستطيع الوكيل فحص كل رسالة وإطلاق تنبيهات دون أن يرسل شيئاً من عنده. هذا هو الفحص السلبي (Passive Scanning)، ولأنه لا يقرأ إلا حركة مرور كنت تتبادلها أصلاً، فإبقاؤه عاملاً أثناء الاختبار المعتاد آمن.

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

• ترويسة غائبة: استجابة بلا Strict-Transport-Security أو Content-Security-Policy.
• ملف تعريف ارتباط ضعيف: ملف جلسة يُضبط بلا السمة Secure أو HttpOnly (RFC 6265).
• تسريب: رمز (token) في سلسلة الاستعلام (query string) لعنوان URL، أو صفحة خطأ تعرض أثر المكدس (stack trace).

جرّبها: محلّل ترويسات الأمان جرّبها: محلّل ملفات تعريف الارتباط (Cookies)

النطاق والإذن الكتابي أولاً

النطاق (scope) هو مجموعة المضيفات والمسارات المسموح لك باختبارها بالضبط. وفي الوكيل تضع علامة «داخل النطاق» على هذه وحدها، وتعرض في السجل الرسائل داخل النطاق فقط، وتقصر الاعتراض وإعادة التشغيل والفحص عليها. وفي ZAP تضيف الهدف إلى سياق (context) مُعلَّم «In Scope»، ويمكنك التبديل إلى الوضع المحمي (Protected mode) الذي يمنع خارج النطاق الأفعالَ التي قد تكون خطرة، مثل الاعتراض وإعادة الإرسال والفحص النشط، كما يمكنك ضبط الفاحص السلبي ليفحص الرسائل داخل النطاق فقط. أما بقية حركة مرور المتصفح، مثل مضيف تحليلات أو أداة طرف ثالث، فتمرّ عادةً عبر الوكيل أيضاً؛ والنطاق هو ما يمنعك من تعديلها أو فحصها.

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

مثال تطبيقي: فحص التحكم في الوصول بإعادة التشغيل

أنت مُصرَّح لك كتابياً باختبار المتجر في بيئة الاختبار التجريبية (staging) لفريقك، وstaging.shop.example داخل نطاق الوكيل. بعد تسجيل الدخول بمستخدم الاختبار الخاص بك، تفتح أحد طلبات الشراء الخاصة بك وتجد طلب HTTP الخاص به في السجل. وفي محرّر الطلبات تغيّر معرّف طلب الشراء وحده إلى معرّف يملكه مستخدم اختبار ثانٍ، وتُبقي ملف تعريف ارتباط جلستك، ثم تعيد الإرسال.

النتيجة الآمنة هي 403 Forbidden أو 404 Not Found: فالخادم يتحقق من أن طلب الشراء يخصّ المستدعي. أما 200 OK مع طلب شراء المستخدم الآخر فهي خلل في التحكم في الوصول، أي مرجع كائن مباشر غير آمن (IDOR)، ولديك بالفعل الطلب والاستجابة بالضبط لتقرير الخطأ.

GET /api/orders/1042 HTTP/1.1
Host: staging.shop.example
Cookie: session=<your own test session>

# Replay with one change: an order id that is not yours
GET /api/orders/1043 HTTP/1.1
Host: staging.shop.example
Cookie: session=<your own test session>

# Secure response:   403 Forbidden  or  404 Not Found
# Broken access control: 200 OK with another user's order

جرّبها: منشئ طلبات API

أسئلة شائعة

المراجع

• OWASP Web Security Testing Guide (WSTG)OWASP Foundationالمنهجية المرجعية لاختبار تطبيقات الويب وواجهات API بحثاً عن نقاط الضعف الأمنية، اختباراً تلو الآخر.
• NIST SP 800-115: Technical Guide to Information Security Testing and AssessmentNIST · 2008كيف تُخطَّط تقييمات الأمان وتُنفَّذ: المراجعة وتحديد الأهداف والتحقق من الثغرات وإعداد التقارير.
• OWASP Top 10:2025OWASP Foundation · 2025أخطر عشرة مخاطر أمنية لتطبيقات الويب، مع كيفية اختبار كل منها والوقاية منه.
• RFC 9110: HTTP SemanticsIETF · 2022معاني أساليب HTTP وحقول الترويسات ورموز الحالة والتفاوض على المحتوى، بغضّ النظر عن إصدار البروتوكول.