الأمن السيبراني وأمن المعلومات

SSRF: كيف يتم الكشف والتحقق الآمن

6 دقيقة قراءةتاريخ النشر: 5 أغسطس 2026
توضيح بصري احترافي حول اختبار SSRF في مجال Web و API PT
إجابة سريعة

يتم اختبار SSRF فقط في المختبر أو في نظام مرخص. يتم فحص الطلب/الاستجابة، سلوك الخادم، الأدوار، الحالة، والتأثير، باستخدام اختبارات حد أدنى لا تضر بالبيانات.

يجب أن يفحص اختبار أمان الويب وواجهة برمجة التطبيقات (API) حدود الثقة، والأذونات، والإدخال، والحالة، ومنطق العمل. كل اختبار في هذه المقالة مخصص للمختبر، أو CTF، أو نظام تم الحصول على إذن صريح بشأنه. تركز هذه المقالة على اختبار SSRF وهي مخصصة لطلاب Web/API PT. الهدف هو توفير منهجية عمل يمكن تطبيقها في التدريب، وفي المقابلات المهنية، وفي بيئة العمل، دون الاكتفاء بالتعريف المعجمي.

التحدي الرئيسي هو أن البيانات غالبًا ما تكون جزئية. يمكن لـ URL fetch feature، وallowlist، وredirects أن تشير إلى اتجاه، ولكن معناها يعتمد على الوقت، والمورد، والمستخدم، والنشاط المتوقع. لذلك، سنبني الاختبار حول سؤال استقصائي، والأدلة المطلوبة، ومعيار واضح للإنجاز.

السيناريو العملي في المقالة هو: الاختبار مقابل Callback محلي في المختبر. جميع الأمثلة هي بيانات مختبرية أو وصف لعمليات. عندما يتعلق الأمر بـ Penetration Testing، أو Web، أو Cloud، يجب العمل فقط بموافقة صريحة، ونطاق محدد، والقدرة على إيقاف الاختبار.

مصادر SSRF

في هذه المرحلة، يتم تحديد الأدلة المطلوبة للإجابة على سؤال التحقيق. بالنسبة لاختبار SSRF، النقاط الأساسية هي الدور والجلسة (Role و session)، ونقطة النهاية والطريقة (Endpoint و method)، والطلب/الاستجابة (Request/Response)، ومعرف الكائن (Object identifier). لكل مصدر، يتم توثيق المالك، ونطاق الاحتفاظ، والمنطقة الزمنية، وتأخير الاستقبال، والحقول التي قد تكون مفقودة.

لا تقاس جودة الجمع بوصول السجل. يجب فحص الاكتمال، والكمون، والتحليل، والأحداث المكررة، ومزامنة الوقت. يسمح اختبار Canary أو حدث مختبر معروف بالتأكد من أن الإجراء ظهر في المصدر، ومر عبر المسار (Pipeline)، ويمكن البحث عنه في الحقول الصحيحة.

تخطيط مدخلات URL

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

في الممارسة العملية، قم بتدوين URL fetch feature، وallowlist، وredirects، وDNS rebinding defenses، وmetadata endpoint، وقارنها بالسلوك المتوقع، وحدد Pivot واحدًا على الأقل. يجب أن تكون النتيجة قابلة للفحص من قبل محلل إضافي، بما في ذلك القيود وخطوات المتابعة.

التحقق مقابل خادم المختبر

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

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

Blind SSRF والتسجيل

في هذه المرحلة، يتم تحديد الأدلة المطلوبة للإجابة على سؤال التحقيق. بالنسبة لاختبار SSRF، النقاط الأساسية هي الدور والجلسة (Role و session)، ونقطة النهاية والطريقة (Endpoint و method)، والطلب/الاستجابة (Request/Response)، ومعرف الكائن (Object identifier). لكل مصدر، يتم توثيق المالك، ونطاق الاحتفاظ، والمنطقة الزمنية، وتأخير الاستقبال، والحقول التي قد تكون مفقودة.

لا تقاس جودة الجمع بوصول السجل. يجب فحص الاكتمال، والكمون، والتحليل، والأحداث المكررة، ومزامنة الوقت. يسمح اختبار Canary أو حدث مختبر معروف بالتأكد من أن الإجراء ظهر في المصدر، ومر عبر المسار (Pipeline)، ويمكن البحث عنه في الحقول الصحيحة.

الاستصلاح وإعادة الاختبار (Remediation و Retest)

يبدأ الاختبار الاحترافي لـ SSRF بشروط النجاح وشروط الفشل. يتم تعريف الحالة الإيجابية، والحالة السلبية، والحالة الحدية، والنشاط المشروع المماثل. وبهذه الطريقة، يمكن تحديد كل من False Negative و False Positive.

في بيئة مرخصة، يتم استخدام إجراء بسيط يثبت الادعاء دون التسبب في ضرر. يتم حفظ الإدخال، والإخراج، والوقت، والإصدار، وبعد التصحيح، يتم إجراء إعادة اختبار (Retest) في نفس السيناريو ويتم فحص التراجع (Regression) على الوظائف المجاورة.

نقاط اختبار فريدة

في هذا الموضوع، يوصى بإنشاء خريطة أدلة مركزة مسبقًا. نقاط الاختبار المركزية هي: URL fetch feature، allowlist، redirects، DNS rebinding defenses، metadata endpoint، egress controls. القائمة ليست قائمة تحقق تلقائية؛ تم اختيار كل عنصر لأنه يمكن أن يربط بين كيان، وعملية، ووقت، أو يشرح سلوكًا مشروعًا.

  • URL fetch feature: حدد القيمة المتوقعة، وما سيعتبر شذوذًا، وأي مصدر إضافي سيتحقق من النتيجة.
  • allowlist: حدد القيمة المتوقعة، وما سيعتبر شذوذًا، وأي مصدر إضافي سيتحقق من النتيجة.
  • redirects: حدد القيمة المتوقعة، وما سيعتبر شذوذًا، وأي مصدر إضافي سيتحقق من النتيجة.
  • DNS rebinding defenses: حدد القيمة المتوقعة، وما سيعتبر شذوذًا، وأي مصدر إضافي سيتحقق من النتيجة.
  • metadata endpoint: حدد القيمة المتوقعة، وما سيعتبر شذوذًا، وأي مصدر إضافي سيتحقق من النتيجة.
  • egress controls: حدد القيمة المتوقعة، وما سيعتبر شذوذًا، وأي مصدر إضافي سيتحقق من النتيجة.

عندما يكون أحد النقاط غير متاح، يجب توثيق الفجوة واختيار بديل. على سبيل المثال، إذا كان Process identifier غير مستقر، يمكن استخدام الوقت، والمضيف (Host)، والمستخدم (User)، والأصل (Parent)؛ إذا كانت الحمولة (Payload) مشفرة، يتم استخدام Metadata، والحجم (Volume)، والتردد (Frequency)، وسياق TLS/DNS.

سير عمل موصى به

  1. حدد نطاقًا وسؤال عمل واحدًا حول اختبار SSRF.
  2. دوّن مصادر البيانات والأدلة المطلوبة: URL fetch feature، allowlist، redirects، DNS rebinding defenses.
  3. أنشئ خط أساس قصيرًا للسلوك السليم أو النتيجة المتوقعة.
  4. قم بإجراء الاختبار الأدنى في بيئة المختبر واحفظ الوقت، والإدخال، والإخراج.
  5. أنشئ جدولًا زمنيًا أو جدول مقارنة وافصل بين الحقيقة والتفسير.
  6. قم بالتحول إلى مصدر إضافي للتحقق من التفسير الأولي أو دحضه.
  7. لخص القرار، والقيود، والإجراء الموصى به، ومعيار إعادة الاختبار (Retest).

سيناريو عملي

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

في نهاية التمرين، يجب تقديم منتج يمكن لمحلل أو مختبر آخر مراجعته: لقطة شاشة أو تصدير للدليل، جدول زمني قصير، افتراض أولي، دليل مؤكد، قيود، وتوصية. عندما لا يكون هناك دليل كافٍ، فإن الاستنتاج الصحيح هو أن السيناريو لم يثبت.

الخطوةماذا يتم التنفيذالمنتج
التحضيرحدد النطاق والوقت والهدف. قم بتدوين الحقول أو الأدلة المتوقع ظهورها من URL fetch feature، allowlist، redirects.خطة اختبار قصيرة
إنشاء بياناتنفذ إجراءً آمنًا ومحاكيًا يتعلق بـ SSRF، بدون معلومات حقيقية أو تأثير على نظام الإنتاج.حدث/طلب/تدفق مراقب
الجمعاجمع الدليل الخام والسياق من مصدر إضافي. تأكد من المنطقة الزمنية، المعرفات، والكمال.دليلان مرتبطان
التحليلاكتب ما يثبته كل دليل، وما لا يثبته، وما هو التفسير المشروع الممكن.استنتاج مؤقت
الانتهاءاختر الإغلاق، أو التصعيد، أو الاكتشاف، أو الضبط؛ أضف توصية وإعادة اختبار (Retest).منتج موثق

قائمة تحقق عملية

  • تحقق ووثق: الدور والجلسة (Role و session).
  • تحقق ووثق: نقطة النهاية والطريقة (Endpoint و method).
  • تحقق ووثق: الطلب/الاستجابة (Request/Response).
  • تحقق ووثق: معرف الكائن (Object identifier).
  • تحقق ووثق: تأثير على جانب الخادم (Server-side effect).
  • تحقق ووثق: التحكم المتوقع والإصلاح (Control expected و remediation).
  • اذكر المنطقة الزمنية، إصدار الأداة، ووقت التجميع.
  • احفظ البيانات الخام قبل التصفية أو التعديل.
  • اكتب ما يثبته الاكتشاف وما لا يزال غير معروف.
  • حدد المالك والإجراء المتبع مع الموعد النهائي.

أخطاء شائعة

  • التحقق من رمز الحالة (Status code) فقط.
  • الاعتماد على التغيير من جانب العميل (Client-side).
  • استخدام حمولة خطيرة (Payload).
  • عدم التحقق من أدوار مختلفة.
  • تجاهل منطق العمل.
  • الإبلاغ بدون طلب/استجابة نظيفة.

ملخص و CTA

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

في مسار Cybersecurity & AI التابع لـ HPI، يتم ممارسة هذه المبادئ من خلال الأنظمة، والسجلات، والمختبرات. الخطوة التالية الطبيعية هي الانتقال إلى المقالات المرتبطة، وإجراء تمرين المختبر، وحفظ المنتج كجزء من محفظة عمل احترافية.

الأسئلة الشائعة

هل يُسمح باختبار SSRF على موقع عام؟

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

ماذا نفعل عندما تكون بعض البيانات مفقودة؟

قم بتوثيق النقص، وتحقق من مصدر بديل، وقلل من مستوى اليقين. لا تملأ الحقول بالافتراض أو تقدم "Unknown" على أنه صحيح.

كم من الوقت يجب الاحتفاظ بالأدلة؟

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

كيف أتدرب دون تعريض نظام حقيقي للخطر؟

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

هل تريد التحقق مما إذا كان هذا المسار يناسبك؟

اترك تفاصيلك وسيتصل بك مستشار من HPI لإجراء مكالمة قصيرة لتقييم الملاءمة، دون أي التزام.

يتم تخزين بياناتك بأمان.

لدراسة SOC والأمن السيبراني ضمن برنامج Cybersecurity & AI

هل ترغب في تفاصيل البرنامج؟ اترك بياناتك وسنتواصل معك.

مقالات ذات صلة