الدليل الكامل لثغرة SSRF (Server-Side Request Forgery): من مبتدئ إلى محترف

Mahmoud Salman    Cyber Security , كورسات    تعليق   

SSRF (Server-Side Request Forgery)

الدليل الكامل لثغرة SSRF (Server-Side Request Forgery): من مبتدئ إلى محترف

أهلاً بك في دليلنا الشامل لواحدة من أخطر الثغرات وأكثرها إثارة للاهتمام في عالم أمن الويب: Server-Side Request Forgery (SSRF). بعد أن انتهيت من دراسة الـ Command Injection، أنت الآن جاهز للانتقال إلى مستوى آخر من التحديات التي تتم من جانب الخادم (Server-Side).

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

---

الجزء 1: ما هي ثغرة SSRF (Server-Side Request Forgery)؟

ببساطة، ثغرة SSRF هي vulnerability (ثغرة أمنية) تسمح للمهاجم (Attacker) بإجبار الخادم (Server) الخاص بتطبيق الويب على إرسال طلبات (HTTP Requests) إلى وجهات لم يكن من المفترض أن يتصل بها.

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

الثغرة تحدث عندما تتمكن من خداع هذا "الموظف" (الخادم) ليقوم بزيارة عناوين داخل الشركة نفسها (الشبكة الداخلية)، أو حتى|

 زيارة نفسه (localhost)، بدلاً من زيارة الرابط العام الذي كان من المفترض أن يزوره.

---

الجزء 2: الفهم الجوهري: كيف تحدث الثغرة تقنيًا؟

تحدث ثغرة SSRF بسبب الثقة الزائدة في مدخلات المستخدم. لنفترض أن لديك ميزة في موقعك تسمح للمستخدم بجلب صورة من رابط (URL) وعرضها.

الكود الضعيف (Vulnerable Pseudo-code) قد يبدو هكذا:

PHP

// PHP (مثال بالكود الزائف)
$url = $_GET['image_url']; // قراءة الرابط من المستخدم مباشرة

// الخادم يقوم بزيارة الرابط الذي أدخله المستخدم لجلب محتواه
$imageData = file_get_contents($url); 

// عرض الصورة للمستخدم
header('Content-Type: image/jpeg');
echo $imageData;

المشكلة هنا واضحة: الخادم يأخذ الـ image_url من المستخدم وينفذ عليه طلب file_get_contents دون أي فلترة أو

 تحقق.

ماذا لو قام المهاجم بتزويد هذا الـ Payload؟

https://example.com/profile.php?image_url=http://localhost/admin

هنا، الخادم سيقوم بزيارة http://localhost/admin بنفسه. أنت كمهاجم لا تستطيع زيارة localhost الخاص بالخادم

 مباشرة من متصفحك، لكنك جعلت الخادم يزورها بالنيابة عنك!

---

الجزء 3: الفرق الجوهري: SSRF مقابل CSRF (خطأ شائع)

من المهم جدًا ألا تخلط بين SSRF و CSRF (Cross-Site Request Forgery).

• CSRF (Cross-Site Request Forgery): تجبر متصفح المستخدم (Client) على إرسال طلب إلى خادم (Server) دون علمه (مثل إجباره على تغيير كلمة المرور). المهاجم يستغل "ثقة الخادم في المتصفح".

• SSRF (Server-Side Request Forgery): تجبر الخادم (Server) على إرسال طلب إلى خادم آخر (قد يكون الخادم نفسه أو خادم داخلي). المهاجم يستغل "ثقة الخادم في نفسه وفي شبكته الداخلية".

لتوضيح الفرق:

الميزة	SSRF (Server-Side)	CSRF (Client-Side)
الوسيط	خادم التطبيق (Your Server)	متصفح الضحية (Victim's Browser)
الهدف	خوادم أخرى (داخلية أو خارجية)	خادم التطبيق (Your Server)
المفهوم	الخادم يُجبَر على إرسال طلب	المستخدم يُجبَر على إرسال طلب

---

الجزء 4: خطورة ثغرة SSRF (The Impact)

لماذا كل هذا القلق حول SSRF؟ لأنها تفتح أبوابًا خلفية خطيرة جدًا. عندما تجعل الخادم يتحدث بالنيابة عنك، يمكنك:

1. مسح الشبكة الداخلية (Internal Network Scanning): اكتشاف الأجهزة والخوادم الأخرى الموجودة على نفس
   
    الشبكة الداخلية مع الخادم المصاب (مثل 192.168.1.x أو 10.x.x.x).
   
   

2. الوصول لخدمات داخلية (Access Internal Services): الوصول إلى لوحات تحكم، قواعد بيانات (مثل Redis)،
   
    أو خدمات (مثل Jenkins, Kibana) التي تعمل على localhost أو على IPs داخلية ولا يمكن الوصول إليها من
   
    الإنترنت.
   
   

3. قراءة ملفات محلية (Read Local Files): في بعض الحالات، يمكن استغلال بروتوكولات أخرى مثل file:/// لقراءة
   
    ملفات حساسة من نظام الخادم نفسه (مثل /etc/passwd).
   
   

4. سرقة بيانات سحابية (Cloud Metadata Theft): وهي الجوهرة الكبرى! مهاجمة خدمات الـ Metadata الخاصة بمزودي الخدمات السحابية (مثل AWS, GCP, Azure) لسرقة مفاتيح الوصول (Access Keys) والسيطرة على الحساب السحابي بالكامل.

---

الجزء 5: النوع الأول: Basic SSRF (أو Full-Response SSRF)

هذا هو النوع الأبسط والأكثر وضوحًا. في هذا النوع، الخادم لا يقوم فقط بإرسال الطلب، بل يعرض لك أيضًا الاستجابة الكاملة (Full Response) التي تلقاها.

المثال الذي ذكرناه في الجزء 2 هو مثال كلاسيكي على Basic SSRF.

• الـ Payload:
  
  

  https://example.com/load?url=http://127.0.0.1/server-status
  
  

• النتيجة:

  المهاجم يرى صفحة server-status الخاصة بخادم Apache (والتي تكون عادة متاحة على localhost فقط) معروضة أمامه في المتصفح.

هذا النوع يسهل اكتشافه واستغلاله لأنك تحصل على تغذية راجعة (Feedback) فورية.

---

الجزء 6: الاستغلال (1): مسح الشبكة الداخلية (Port Scanning)

بمجرد اكتشاف ثغرة SSRF، أول ما قد تفعله هو فهم "الجيران" المحيطين بالخادم. يمكنك استخدام الثغرة كأداة Port Scanner.

ستقوم بإرسال Payloads مختلفة لاختبار الـ IPs والـ Ports الداخلية.

• الـ Payload (مثال):
  
  

  • http://192.168.1.1:80



  • http://192.168.1.1:8080



  • http://10.0.0.5:22



  • http://10.0.0.5:6379 (Redis)
    
    

ستحلل الاستجابة من الخادم (Response) لتحديد ما إذا كان الـ Port مفتوحًا أم مغلقًا.

تحليل الاستجابة (مثال)	الدلالة المحتملة
Response سريع + "Connection Refused"	الـ IP موجود، لكن الـ Port مغلق.
Timeout طويل جدًا	الـ IP غير موجود أو firewall يمنع الوصول.
Response يحتوي على (e.g., "HTTP/1.1 200 OK")	الـ Port مفتوح ويعمل عليه خدمة (HTTP).
Response غريب (e.g., "SSH-2.0...")	الـ Port مفتوح ويعمل عليه خدمة (SSH).

---

الجزء 7: الاستغلال (2): الوصول للوحات التحكم الداخلية (Admin Panels)

العديد من التطبيقات والخدمات (مثل Elasticsearch, Kibana, Jenkins, Tomcat) تقوم بتشغيل واجهة تحكم (Admin

 Panel) على localhost (أو 127.0.0.1) بشكل افتراضي، وتفترض أنها آمنة لأن لا أحد من الخارج يستطيع الوصول

 إليها.

هنا يأتي دور SSRF.

• السيناريو: تطبيق Kibana (لتحليل الـ logs) يعمل على الخادم المصاب على http://localhost:5601 وهو غير
  
   متاح للعامة.

• الـ Payload:
  
  

  https://example.com/load?url=http://localhost:5601/app/kibana
  
  

• النتيجة:

  الخادم المصاب يقوم بزيارة لوحة تحكم Kibana بالنيابة عنك، وقد يعرضها لك بالكامل (في حالة Basic SSRF)، مما يمنحك وصولاً كاملاً إليها.

---

الجزء 8: الاستغلال (3): استخدام بروتوكولات خطيرة (Protocol Wrappers)

SSRF لا تقتصر على بروتوكول http:// أو https://. الـ Endpoint الضعيف قد يدعم Wrappers (أغلفة) أخرى

 يمكن أن تسبب ضررًا هائلاً.

هذا يعتمد على المكتبة البرمجية التي يستخدمها الخادم (مثل cURL).

البروتوكول (Wrapper)	مثال الـ Payload	الاستخدام الخبيث (Malicious Use)
file:///	file:///etc/passwd	قراءة ملفات محلية من نظام تشغيل الخادم.
dict://	dict://localhost:6379/INFO	إرسال أوامر مخصصة لخدمات (مثل Redis) لا تستخدم HTTP.
gopher://	(Payload معقد)	بروتوكول مرن جدًا، يمكن استخدامه لبناء طلبات HTTP (بما فيها POST) أو طلبات لخدمات أخرى (مثل MySQL, SMTP) لخداعها.
ldap://	ldap://internal-ldap-server	الاستعلام عن خدمات LDAP الداخلية.

استخدام file:/// هو من أشهر طرق استغلال SSRF لتحويلها إلى ثغرة قراءة ملفات (LFI - Local File Inclusion).

---

الجزء 9: الهدف الأكبر: اختراق البيئات السحابية (Cloud Metadata) ☁️

هذا هو السيناريو الأخطر على الإطلاق في عصرنا الحالي. مزودو الخدمات السحابية (AWS, Google Cloud, Azure) لديهم خدمة Metadata داخلية. هذه الخدمة هي API (واجهة برمجة تطبيقات) تعمل على IP ثابت "سحري" لا يمكن الوصول إليه إلا من داخل الخادم السحابي (Instance) نفسه.

هذه الخدمة تحتوي على معلومات حساسة، بما في ذلك مفاتيح الوصول المؤقتة (Temporary Access Credentials) الخاصة بالـ Instance.

• الـ IP السحري في AWS: http://169.254.169.254



• الـ Payload (مثال لسرقة مفاتيح AWS):
  
  

  https://example.com/load?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE_NAME]
  
  

• النتيجة:

  الخادم سيعرض للمهاجم بيانات JSON تحتوي على AccessKeyId, SecretAccessKey, و Token. باستخدام هذه المفاتيح، يمكن للمهاجم السيطرة على حساب AWS الخاص بالضحية بالكامل.

---

الجزء 10: النوع الثاني: Blind SSRF 

وماذا لو كان الخادم لا يعرض لك الاستجابة (Response)؟ ماذا لو كان الـ Endpoint الضعيف يقوم فقط بـ "ping" للرابط

 الذي أعطيته إياه، أو يجلبه لمعالجته في الخلفية دون أن يريك النتيجة؟

هذه تسمى Blind SSRF .

هنا، لا يمكنك رؤية server-status أو ملف /etc/passwd. الاستغلال يصبح أصعب، لكنه ليس مستحيلاً. أنت تعتمد على

 "إشارات" أخرى لتأكيد وجود الثغرة واستغلالها.

---

الجزء 11: استغلال Blind SSRF (الجزء الأول): كشف الثغرة (Out-of-Band)

لكي تؤكد وجود ثغرة Blind SSRF، أنت بحاجة إلى "شاهد" خارجي.

1. ستستخدم خدمة مثل Burp Collaborator أو أي خادم VPS تملكه (دعنا نسميه attacker-server.com).
   
   

2. ستقوم بإرسال Payload يطلب من الخادم المصاب زيارة الخادم الخاص بك:
   
   

   https://example.com/vulnerable?url=http://[YOUR_BURP_COLLABORATOR_ID].burpcollaborator.net
   
   

3. ستراقب الـ logs (السجلات) على خادمك (Burp Collaborator).
   
   

4. النتيجة: إذا رأيت طلب (HTTP request) أو (DNS query) قادمًا من الـ IP الخاص بالخادم المصاب، فهذا يثبت 100% أن الخادم نفذ طلبك. لقد أكدت وجود ثغرة Blind SSRF.

---

الجزء 12: استغلال Blind SSRF (الجزء الثاني): تحليل الأخطاء (Error-Based)

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

• الـ Payload 1: http://localhost:12345 (Port مغلق على الأغلب)
  
  

  • رسالة الخطأ: Failed to connect. (استغرق 0.1 ثانية)
    
    

• الـ Payload 2: http://10.0.0.1 (IP غير موجود في الشبكة)
  
  

  • رسالة الخطأ: Request timed out. (استغرق 30 ثانية)
    
    

• الـ Payload 3: http://localhost:8080/admin (Port مفتوح ولوحة تحكم موجودة)
  
  

  • رسالة الخطأ: Invalid data received. (استغرق 0.5 ثانية)
    
    

لاحظ الاختلاف في رسائل الخطأ وفي وقت الاستجابة (Response Time). هذا الاختلاف وحده كافٍ لعمل مسح للشبكة الداخلية (Port Scanning) حتى لو كانت الثغرة "عمياء".

---

الجزء 13: أين تبحث عن ثغرات SSRF؟ (Testing Endpoints)

عندما تختبر تطبيقًا، ركز على أي ميزة تطلب من الخادم جلب مورد (Resource) بناءً على رابط (URL) أو حتى IP من المستخدم.

• المكان الواضح:

  • ميزة "رفع صورة من رابط" (Image upload from URL).

  • ميزة "استيراد مقال من رابط" (Import article from URL).

  • أدوات فحص الـ SEO التي تطلب منك إدخال رابط موقعك.

• المكان الأقل وضوحًا (Hidden):

  • Webhooks: عندما تسمح للمستخدم بتحديد URL ليتم إرسال إشعارات إليه.

  • مولدات الـ PDF/الصور: ميزة "طباعة الصفحة كـ PDF". غالبًا ما يقوم الخادم بزيارة الرابط الذي أدخلته (أو الرابط الحالي) ليقوم بعمل rendering له.
    
    

  • أي باراميتر في الـ URL أو الـ JSON Body يحتوي على رابط كامل (e.g., ?return_url=, ?

next_page=, {"source_url": ...}).
    
    

---

الجزء 14: تقنيات تجاوز الحماية (Bypass 1): خداع فلاتر الـ IP

غالبًا ما يضع المطورون "Blacklist" (قائمة سوداء) لمنع الـ Payloads الواضحة مثل 127.0.0.1 أو localhost أو

  169.254.169.254.

PHP

// فلتر ضعيف 
if ( str_contains($url, '127.0.0.1') || str_contains($url, 'localhost') ) {
    die('Attack detected!');
}

يمكنك تجاوز هذا الفلتر بسهولة عن طريق استخدام صيغ بديلة للـ IP لا تزال تشير إلى localhost:

نوع التشفير	الـ Payload البديل لـ 127.0.0.1
Hex (سداسي عشري)	http://0x7f000001
Octal (ثماني)	http://0177.0.0.1
Decimal (عشري)	http://2130706433
IPv6	http://[::1] (إذا كان الخادم يدعم IPv6)
استخدام نطاق	http://127.0.0.1.nip.io (نطاق سحري يحل أي IP بداخله)
خلط	http://0177.0.0.0x1

---

الجزء 15: تقنيات تجاوز الحماية (Bypass 2): خداع فلاتر الـ Domains

ماذا لو كان الفلتر يفرض أن الرابط يجب أن يبدأ بـ https://safe.example.com؟

PHP

// فلتر ضعيف آخر (مثال)
if ( ! $url->startsWith('https://safe.example.com') ) {
    die('Only our domain is allowed!');
}

هنا يمكنك استخدام خدع DNS وتركيب الـ URL:

1. استخدام @: المتصفحات والمكتبات القديمة كانت تعتبر ما قبل @ هو (username:password).
   
   

   • الـ Payload: https://safe.example.com@attacker.com



   • النتيجة: الخادم يظن أنه يزور safe.example.com، لكنه في الحقيقة يزور attacker.com.
     
     

2. استخدام خدع الـ DNS:
   
   

   • الـ Payload: https://safe.example.com.attacker.com



   • النتيجة: إذا كنت تملك نطاق attacker.com، يمكنك إنشاء subdomain بهذا الاسم، وسيقوم الفلتر بتمريره.
     
     

3. استخدام Redirects:
   
   

   • أنشئ صفحة على https://safe.example.com/redirect.php (إذا كان الموقع يسمح بذلك) تقوم بإعادة
     
      التوجيه (302 Redirect) إلى http://169.254.169.254.
     
     

   • الـ Payload: https://safe.example.com/redirect.php



   • النتيجة: الفلتر يرى النطاق سليمًا، ولكن الخادم سيتبع الـ Redirect إلى الـ IP الخبيث.
     
     

---

الجزء 16: الحماية (Mitigation): كيف يدافع المطورون عن تطبيقاتهم؟

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

1. الحل الأقوى: Whitelist (القائمة البيضاء) 
   
   

   • لا تستخدم Blacklist أبدًا، فهي مكسورة دائمًا.
     
     

   • بدلاً من ذلك، قم بإنشاء Whitelist (قائمة بيضاء) صارمة جدًا بالنطاقات أو الـ IPs المسموح للخادم بزيارتها فقط.
     
     

   • مثال: السماح فقط لـ api.google.com و api.facebook.com. أي شيء آخر يتم رفضه.
     
     

2. تعطيل البروتوكولات غير المستخدمة:
   
   

   • في مكتبة cURL (أو غيرها)، قم بتعطيل كل البروتوكولات (Wrappers) التي لا تحتاجها صراحةً. لا تسمح بـ
     
       file:///, dict://, gopher://, ldap:// إذا كان كل ما تحتاجه هو http:// و https://.
     
     

3. عزل الخادم (Network Segmentation):
   
   

   • لا تجعل الخادم الذي يواجه الإنترنت (Web Server) قادرًا على "رؤية" الشبكة الداخلية بالكامل.
     
     

   • استخدم Firewall Rules لمنع الخادم من بدء اتصالات (Egress traffic) إلى الـ IPs الداخلية (مثل
     
       10.x.x.x, 192.168.x.x) أو إلى IP خدمة الـ Metadata السحابية (169.254.169.254).
     
     

4. في البيئات السحابية (AWS/GCP):
   
   

   • استخدم IMDSv2 (Instance Metadata Service Version 2) في AWS. هذا يضيف هيدر (Header) خاص للطلب ويجعل استغلال SSRF شبه مستحيل للوصول للـ Metadata.

---

أنت الآن تملك فهماً عميقاً لثغرة SSRF. لقد رأيت كيف يمكن لـ Endpoint بسيط لجلب الصور أن يتحول إلى كابوس أمني

 يسمح بسرقة بيانات سحابية أو اختراق الشبكة الداخلية بالكامل. تذكر دائمًا، الأمان يبدأ من "عدم الثقة" (Zero Trust).