تخطَّ إلى المحتوى

🛡️ شرح الأمن السيبراني

الحماية من SSRF

الدرس 25 من 29· ⏱ 3 دقائق قراءة

📚 محتوى دفاعي بحت: الهدف منع الثغرة في كودك.

ما هي SSRF؟

Server-Side Request Forgery: تحدث عندما يقبل الخادم رابطًا (URL) من المستخدم ثم يزوره بنفسه دون التحقّق من وجهته — فيتحوّل الخادم إلى وسيط يرسل طلبات نيابة عن المهاجم لأماكن ما كان يفترض أن يصلها أحد من الخارج.

مثال شائع: ميزة "استورد صورة من رابط" أو "تحقّق من موقع Webhook" — الخادم يطلب الرابط المُدخَل مباشرة.

لماذا هي خطيرة؟

الخادم عادة موثوق بالشبكة الداخلية بشكل لا يتمتّع به أي زائر خارجي. لو أقنع مهاجم الخادم بزيارة رابط داخلي بدل رابط خارجي، يمكنه:

  • مسح الشبكة الداخلية ومعرفة الخدمات المفتوحة.
  • الوصول لخدمات لا تتطلّب مصادقة من الشبكة الداخلية (قواعد بيانات، لوحات إدارة).
  • الأخطر: الوصول لخدمة بيانات وصف السحابة (Cloud Metadata) المتاحة عادة على عنوان ثابت مثل 169.254.169.254، والتي قد تُرجع بيانات اعتماد مؤقّتة لصلاحيات الخادم على AWS/GCP/Azure.

كيف تحدث (مفهوميًّا)

المستخدم يرسل: importUrl = "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
الخادم (بثقة كاملة) يزور هذا الرابط بنفسه ويعيد محتواه للمستخدم

لو لم يتحقّق الخادم من وجهة الرابط، لا فرق عنده بين صورة عامة على الإنترنت وخدمة داخلية حسّاسة — كلاهما "رابط يُزار".

الدفاع: قائمة بيضاء لا قائمة سوداء

⚠️ محاولة حظر عناوين معيّنة (قائمة سوداء) قابلة للالتفاف دائمًا — عبر إعادة توجيه HTTP، أو تنسيقات عنوان بديلة (decimal/hex)، أو DNS rebinding. القاعدة الوحيدة الموثوقة: اسمح بما تعرفه فقط.

  • لا تقبل رابطًا كاملًا من المستخدم إن أمكن — اطلب معرّفًا (ID) وابحث عن الوجهة من قائمة مضبوطة على الخادم.
  • إن كان لا بدّ من رابط، تحقّق من النطاق (domain) مقابل قائمة بيضاء صريحة قبل إرسال الطلب.
  • عطّل اتباع إعادة التوجيه (follow redirects) تلقائيًّا — رابط ظاهره آمن قد يُعيد التوجيه لعنوان داخلي.
  • امنع الوصول من الخادم للنطاقات الخاصة (127.0.0.1, 169.254.169.254, 10.0.0.0/8, وغيرها) على مستوى الشبكة (جدار حماية) لا الكود فقط — طبقة دفاع إضافية.
  • في السحابة: استخدم IMDSv2 على AWS (يتطلّب توكن بطلب إضافي، يصعّب استغلاله عبر SSRF بسيط) بدل النسخة القديمة المفتوحة.
// مثال دفاعي: تحقّق من النطاق مقابل قائمة بيضاء قبل أي طلب من الخادم
const ALLOWED_HOSTS = new Set(["images.trusted-cdn.com", "api.partner.com"]);

function isSafeUrl(rawUrl) {
  try {
    const url = new URL(rawUrl);
    if (url.protocol !== "https:") return false;   // لا http عادي ولا file:
    return ALLOWED_HOSTS.has(url.hostname);          // قائمة بيضاء صريحة
  } catch {
    return false; // رابط غير صالح أصلًا
  }
}

if (!isSafeUrl(userProvidedUrl)) return badRequest();

دفاع متعدّد الطبقات

  1. طبقة التطبيق: قائمة بيضاء للنطاقات + منع إعادة التوجيه.
  2. طبقة الشبكة: جدار حماية يمنع الخادم من الوصول للنطاقات الداخلية أصلًا (deny by default).
  3. طبقة السحابة: IMDSv2 أو ما يعادلها، وتقييد صلاحيات دور الخادم لأقلّ ما يلزم.

💡 حتى لو نجح مهاجم بتمرير SSRF، دور الخادم بصلاحيات محدودة (أقلّ صلاحية) يقلّل الضرر الفعلي بشكل كبير.

🎯 التالي: الحماية من IDOR.

شرح الحماية من SSRF — الأمن السيبراني بالعربي
الحماية من SSRFالأمن السيبراني بالعربي · The Code Fix

📚 لمزيد من التعمّق في الأمن السيبراني، راجِع OWASP — مرجع أمن التطبيقات.

هل كان هذا الدرس مفيدًا؟