ثغرة HTTP Request Smuggling شرح مبسط للمطورين

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

ببساطة كدا، الثغرة دي بتخلي الـattacker يبعَت HTTP requests بطريقة تخلي الـweb-server أو الـproxy يقرأها غلط - وده بيسمح له يخلي طلبات تتنفذ باسم مستخدمين تانيين أو يدخل طلبات بتاعتُه وسط ترافيك الناس التانية. يعني ممكن يخفي request جواه request تاني - وده خطر كبير.

شوية مفاهيم لازم تعرفها الأول ​

TCP connection وHTTP/1.1 - ليه الكلام ده مهم؟​

لما تبعت HTTP request بيتفتح TCP-Link بينك وبين السيرفر. علشان نقلل إعادة الـhandshake وإحنا شغالين، HTTP/1.1 جاب حاجتين مهمين:

• Connection: keep-alive - يبقي TCP-Link مفتوح عشان تتبعت requests أكتر بنفس الاتصال.
• Pipelining - المتصفح يبعَت طلبات كتير مرة واحدة، والسيرفر يرد عليهم بالترتيب (FIFO).

دي الحاجات بتزود السرعة لكن بتفتح مساحات للـattack لما يكون في Proxy / CDN بين الزبون والسيرفر الحقيقي.

CDN / Proxy = Front-end، والسيرفر الحقيقي = Back-end ​

الـCDN أو الـProxy بيكون قدام (front-end) ويعطي نسخة من الموقع للناس علشان تحمل أسرع. لكن المشكلة بتحصل لما front-end وback-end يتعاملوا مع نفس الـHTTP request بشكل مختلف - ودي نقطة الانهيار.

اللعب على الـHeaders: Content-Length و Transfer-Encoding ​

الاتنين دول هما مفتاح اللعبة:

• Content-Length: رقم بيقول لك قد ايه طول الـmessage body (بالبايت).
• Transfer-Encoding: بيقول إزاي الـbody متقسَّم - أهم قيمة عندنا هنا: chunked.

لو استخدمت الاتنين في نفس الـrequest، فالقواعد بتقول إن Transfer-Encoding ليه أفضلية ويتجاهلوا Content-Length. لكن بعض الـproxies أو الـbackends ممكن يكونوا مختلفين - وده الي بيخلي الهجوم ممكن.

مثال بسيط على chunked:​

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

6\r\n
QWERTY\r\n
2\r\n
HI\r\n
0\r\n
\r\n

الـ6 دي حجم الـchunk بالهكس، والـ0 معناها نهاية الـbody.

إزاي الـattacker يستغل الاختلاف ده؟ ​

الفكرة العامة: تبعت request واحد ظاهره عادي، لكن جواه request تاني مُخبّى. الـfront-end ممكن يفسر نهاية الـrequest بطريقة، والـback-end بطريقة تانية - وده يخلي الـback-end يشوف request إضافي وينفذه على أنه request جديد من user تاني.

في ثلاث سيناريوهات رئيسية بتتكرّر كتير:

CL.TE (Content-Length أمام Transfer-Encoding)​

الـfront-end يقرأ Content-Length فقط، والـback-end يقرأ Transfer-Encoding فقط.
المهاجم يخلي الـfront-end يمرر كل البايتات للـback-end عشان الـback-end يلاقي request تاني بعد ما يخلص الأول ويشغّله باسم مستخدم تاني.

مثال مبسّط:

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

0

GET /admin HTTP/1.1

الـfront-end يشوف طول 24 ويبعت كل البايتات، لكن الـback-end لما يعالج chunked يظن إن الـbody خلّص عند الـ0 وبعدين يلاقي GET /admin ويشغّله!

TE.CL (Transfer-Encoding قدّام Content-Length)​

الـfront-end بيطبّق chunked فالـrequest ينتهي مبكر، وبعدين يمرّر الباقي، والـback-end بيقرأ Content-Length ويحسب غلط - وده برضه بيولد smuggled request.

CL.CL (اتنين Content-Length)​

تبعت header فيه Content-Length اتنين أرقام أو تكرار - بعض السيرفرات تتعامل مع الحالة بشكل غير صحيح وتفتح مجال للاختراق.

إمتى يستخدمها الهكر وإيه الأضرار؟ ​

الـimpact بيعتمد على السيناريو:

• تنفيذ طلبات باسم مستخدمين تانيين (session hijacking).
• عمل web-cache poisoning أو خداع الـcache.
• تسليم سكريبتات SELF-XSS أو سرقة بيانات.
• التقاط requests لعمل Replay أو تزوير.

ازاي تزود فرص نجاح الهجوم؟ (يعني إزاي تحمي بدل كدا) ​

• افترض إن الـfront-end و الـback-end ممكن يتصرفوا مختلف - ما تعتمدش على header واحد لتحديد نهاية الـbody.
• فعل قواعد صارمة للتحقق من التوافق بين Content-Length و Transfer-Encoding.
• حسّن إعدادات الـproxy والـweb-server بحيث لو لقى تعارض يرجّع 400 وما يمرّرش البايتات.
• حدّث الـservers والـproxies لنسخ ما بتتأثرش بالـambiguities دي.
• اختبر انظمتك عمليًا على أدوات زي PortSwigger labs (ممتاز لتعلم request smuggling عمليًا).

فين تجرب بنفسك؟ ​

أنصح وبشدة تشتغل على مختبرات تعليمية زي PortSwigger labs - شرحوها بطريقة عملية وممكن تعمل كل السيناريوهات بنفسك:
https://portswigger.net/web-security/request-smuggling

خلاصة سريعة ​

• الـHTTP Request Smuggling بيستغل اختلاف تعامل الـfront-end (proxy/CDN) والـback-end مع headers زي Content-Length وTransfer-Encoding.
• الهجوم بسيط في الفكرة لكنه خطير جدًا في الأثر.
• لازم تعمل hardening للـproxy والسيرفر وتتأكد إن الاتنين متوافقين في تفسير نهاية الـrequest.