ثغرة HTTP Request Smuggling: كل اللي لازم تعرفه

لو بتشتغل في اختبار الاختراق (Penetration Testing) أو أمن الويب، يبقى لازم تسمع عن ثغرة HTTP Request Smuggling، واحدة من الثغرات اللي ممكن تكون مدمرة لو اتقنتها!

الثغرة دي بتسمح للمهاجم يبعت طلبات HTTP مضروبة تخلّي السيرفر ينفذ طلبات خبيثة على مستخدمين تانيين.

في البوست ده، هنشرح إيه هي الثغرة دي، إزاي بتحصل، إزاي تختبرها، وإزاي تحمي نفسك منها، مع أمثلة عملية ونصايح للـ Red Team وWeb Admins في 2026. خلّيك معانا عشان تفهم الثغرة دي زي المحترفين!

إيه هي ثغرة HTTP Request Smuggling؟ ​

بالبلدي، HTTP Request Smuggling هي ثغرة بتحصل لما المهاجم يبعت طلب HTTP (Request) فيه طلب تاني مخفي جواه، ويستغل الفرق في طريقة تعامل الـ Front-End Server (زي Proxy أو CDN) مع الـ Back-End Server (السيرفر الحقيقي). النتيجة؟ السيرفر الخلفي ينفذ الطلب المخفي (الـ Smuggled Request) كأنه طلب حقيقي من مستخدم تاني، وده ممكن يوصل لأضرار زي سرقة بيانات أو تحويل Self-XSS لـ Reflected XSS.

الثغرة دي بتعتمد على عدم توافق (Desync) بين السيرفرين في قراءة الـ Headers زي Content-Length وTransfer-Encoding. لو السيرفرين مش متفقين، المهاجم بيقدر يلعب بالطلبات ويخلّي السيرفر يتصرف بطريقة غلط.

مفاهيم أساسية لازم تعرفها قبل الثغرة ​

عشان تفهم HTTP Request Smuggling، لازم تكون فاهم المفاهيم دي:

• HTTP/1.1 وKeep-Alive: في HTTP/1.1، الـ Keep-Alive بيخلّي الـ TCP Connection مفتوح بين العميل والسيرفر عشان توفير الموارد وتسريع الاتصال. يعني بدل ما كل طلب يفتح ويقفل اتصال، الكل بيستخدم نفس الاتصال.
• Pipelining: بيسمح للمتصفح يبعت أكتر من طلب مرة واحدة من غير ما يستنى الرد، والسيرفر بيرد بنظام FIFO (First In, First Out). ده بيزود السرعة، بس لو اتلعب فيه، ممكن يحصل فوضى.
• CDN (Content Delivery Network): شبكة سيرفرات موزعة حول العالم عشان تسرّع تحميل المواقع. مثلاً، لو موقعك في مصر وواحد من الصين بيتصفح، الـ CDN بيحمل الموقع من سيرفر قريب منه جغرافيًا. السيرفر ده بيتقسم لـ Front-End Server (Proxy) وBack-End Server (السيرفر الحقيقي).
• Content-Length: Header بيحدد حجم الـ Request Body بالبايتس. مثلاً:
  

  POST /index.html HTTP/1.1
  Host: example.com
  Content-Length: 6
  
  QWERTY

  هنا الـ Content-Length: 6 يعني الـ Body هو 6 بايتس (كلمة QWERTY).
• Transfer-Encoding: chunked: Header بيقسم الـ Request Body لقطع (Chunks)، كل قطعة ليها حجم بالهيكساديسيمال، وينتهي بـ 0\r\n. مثال:
  

  POST / HTTP/1.1
  Host: example.com
  Transfer-Encoding: chunked
  
  6
  QWERTY
  2
  HI
  0

  هنا الـ Body مقسّم لقطعتين: QWERTY (6 بايتس) وHI (2 بايتس).

إزاي الثغرة بتحصل؟ ​

الثغرة بتحصل بسبب عدم توافق بين الـ Front-End Server والـ Back-End Server في طريقة قراءة الـ Headers (Content-Length وTransfer-Encoding). المهاجم بيستغل الفرق ده عشان يبعت طلب (Smuggled Request) مخفي جوا طلب عادي. الـ Proxy بيشوف الطلب كله عادي ويمرره، لكن الـ Back-End بيشوفه كطلبين منفصلين، فيعمل مشكلة.

أنواع HTTP Request Smuggling ​

فيه 3 أنواع رئيسية للثغرة:
1. CL.TE (Content-Length, Transfer-Encoding): الـ Front-End يقرأ Content-Length بس، والـ Back-End يقرأ Transfer-Encoding بس.

   POST / HTTP/1.1
   Host: example.com
   Content-Length: 24
   Transfer-Encoding: chunked

   0

   GET /admin HTTP/1.1

- الـ Front-End بيشوف Content-Length: 24، فيبعت الطلب كله (مع الـ Smuggled Request) للـ Back-End.
- الـ Back-End بيشوف Transfer-Encoding: chunked، فلما يلاقي 0\r\n بيفتكر إن الطلب خلّص، لكن بعدها بيشوف GET /admin HTTP/1.1 ويعتبره طلب جديد. لو مستخدم تاني بعت طلب، السيرفر هينفذ الـ GET /admin بداله!

2. TE.CL (Transfer-Encoding, Content-Length): الـ Front-End يقرأ Transfer-Encoding بس، والـ Back-End يقرأ Content-Length بس.

   POST / HTTP/1.1
   Host: example.com
   Content-Length: 4
   Transfer-Encoding: chunked

   12
   GPOST / HTTP/1.1
   0

- الـ Front-End بيشوف Transfer-Encoding: chunked، فلما يلاقي 0\r\n بيبعت الطلب كله للـ Back-End.
- الـ Back-End بيشوف Content-Length: 4 (الـ 12 وnewline)، فيعتبر الـ GPOST / HTTP/1.1 طلب جديد، وينفذه على المستخدم التالي.

3. CL.CL (Content-Length, Content-Length): المهاجم بيبعت طلب فيه اتنين Content-Length بقيم مختلفة، وبعض السيرفرات مش بتتعامل معاها صح.

   POST / HTTP/1.1
   Host: example.com
   Content-Length: 4
   Content-Length: 30

   1234
   GET /admin HTTP/1.1

- لو الـ Front-End قرأ القيمة الأولى والـ Back-End قرأ التانية، الـ Smuggled Request هيعدي.

ملحوظة: دايمًا استخدم POST في الـ Smuggling، لأن GET مش بيحمل Body، فالثغرة بتبقى أصعب.

تأثير الثغرة (Impact) ​

حسب السيناريو، الثغرة ممكن تسبب:

• تحويل Self-XSS لـ Reflected XSS: تخلّي هجوم بسيط يتحول لهجوم خطير على مستخدمين تانيين.
• سرقة طلبات المستخدمين: المهاجم يقدر يشوف طلبات زي كوكيز أو بيانات حساسة.
• Web Cache Poisoning: تزوير محتوى الـ Cache عشان يظهر محتوى خبيث للمستخدمين.
• Request Confusion: خلط الطلبات بين المستخدمين، ممكن يخلّي مستخدم ينفذ طلبات المهاجم.

إزاي تختبر الثغرة؟ ​

عشان تختبر HTTP Request Smuggling، لازم تشتغل في بيئة آمنة (Lab) أو بإذن من صاحب الموقع. إليك الخطوات:

• حدد السيرفرات: تأكد إن الموقع بيستخدم Proxy (زي Cloudflare) مع Back-End Server.
• جرب أدوات تلقائية: زي Burp Suite مع Turbo Intruder لإرسال طلبات Smuggled.
• ابعت طلبات معدلة: استخدم الـ Headers زي Content-Length وTransfer-Encoding مع قيم مختلفة.
• راقب الاستجابة: لو السيرفر نفّذ طلبك الخبيث (زي GET /admin)، يبقى الثغرة موجودة.

اختبار عملي على PortSwigger Labs ​

https://portswigger.net/web-security/request-smuggling هي منصة رائعة لتجربة الثغرة:

• افتح Burp Suite، واضبط الـ Proxy.
• جرب أنواع الـ Smuggling (CL.TE، TE.CL، CL.CL) على Labs زي:
  

  POST / HTTP/1.1
  Host: example.com
  Content-Length: 24
  Transfer-Encoding: chunked
  
  0
  
  GET /admin HTTP/1.1

• راقب لو السيرفر نفّذ الـ GET /admin على مستخدم تاني.

PortSwigger بيشرح الثغرة بطريقة بسيطة وفيها Labs عملية، فجربها بنفسك!

إزاي تحمي نفسك من HTTP Request Smuggling؟ ​

عشان تحمي موقعك أو تطبيقك:

• وحد الـ Headers: خلّي السيرفر يرفض أي طلب فيه Content-Length وTransfer-Encoding مع بعض.
• حدّث السيرفرات: تأكد إن الـ Proxy والـ Back-End يستخدموا نفس إصدار HTTP Protocol (يفضل HTTP/2 لأنه أقل عرضة).
• استخدم WAF: زي Cloudflare WAF، بس ظبّط القواعد عشان تكتشف الطلبات المشبوهة.
• راقب الـ Logs: شوف لو فيه طلبات غريبة أو Errors زي 400 Bad Request.
• اختبر باستمرار: استخدم أدوات زي Burp Suite أو HTTP Smuggler لفحص موقعك.

نصايح للمحترفين في 2026​

• جرب HTTP/2: الثغرة أقل شيوعًا في HTTP/2، بس لازم تختبر كويس لأن فيه Variants جديدة.
• دمج مع أدوات تانية: استخدم Burp Suite مع Turbo Intruder أو smuggler.py.
• تعلم من PortSwigger: Labs بتاعتهم بتغطي كل السيناريوهات.
• اختبر في Lab: اعمل بيئة وهمية بـ Docker تحاكي Proxy وBack-End.
• تابع التحديثات: في 2025، ظهرت تقنيات جديدة زي H2C Smuggling، فخلّيك متابع.

موارد إضافية لتعلم HTTP Request Smuggling ​

• https://portswigger.net/web-security/request-smuggling: شرح وLabs من PortSwigger.
• https://github.com/defparam/smuggler: أداة smuggler.py لاختبار الثغرة.
• https://owasp.org/www-community/attacks/HTTP_Request_Smuggling: شرح OWASP عن الثغرة.
• كتاب Web Application Hacker’s Handbook: مرجع لثغرات الويب.

الخلاصة ​

HTTP Request Smuggling ثغرة خطيرة بتستغل عدم التوافق بين الـ Front-End والـ Back-End Servers في قراءة Content-Length وTransfer-Encoding. المهاجم بيقدر يخفي طلب خبيث جوا طلب عادي، ويخلّي السيرفر ينفذه على مستخدمين تانيين. جرب الثغرة في https://portswigger.net/web-security/request-smuggling، واستخدم أدوات زي Burp Suite عشان تختبرها بأمان. لو بتدير موقع، ظبّط السيرفرات وحط طبقات حماية زي WAF.