تهريب طلبات HTTP: هجمات CL.TE وTE.CL وتخفيض بروتوكول HTTP/2

تُعد ثغرة تهريب طلبات HTTP (HTTP Request Smuggling) واحدة من أخطر فئات الثغرات الأمنية وأكثرها تعقيداً في معمارية تطبيقات الويب الحديثة. تم توثيق هذه الفئة لأول مرة في عام 2005 من قبل باحثي Watchfire، ثم أعاد الباحث الأمني جيمس كيتل (James Kettle) تسليط الضوء عليها بأبحاثه الرائدة، مبيناً كيف تستغل هذه الهجمات التباين والاختلاف في تفسير حدود طلبات HTTP بين خوادم البروكسي العكسية في الواجهة الأمامية (مثل خوادم موازنة الأحمال، شبكات CDN، وجدران حماية تطبيقات الويب WAF) وخوادم التطبيقات الخلفية في الواجهة الخلفية (Backend Servers).

عندما ينجح المهاجم في إحداث اختلال في التزامن (Desynchronization) بين الخوادم، يمكنه دس طلب HTTP خبيث مباشرة داخل اتصال TCP المشترك والمستمر بين البروكسي والخادم الخلفي. يظل هذا الطلب المهرب قابعاً بهدوء في ذاكرة التخزين المؤقت لمقبس الشبكة (Socket Buffer)، حتى يرسل مستخدم شرعي آخر طلبه التالي، فيتم دمج طلب الضحية بالطلب المهرب تلقائياً. تتراوح آثار هذا الهجوم بين التجاوز التام للمصادقة والاستيلاء على الصلاحيات الإدارية، وسرقة بيانات اعتماد الجلسات بين المستخدمين، وتسميم الذاكرة المؤقتة (Cache Poisoning)، وصولاً إلى الاختراق الكامل والمستمر للتطبيقات.

يقدم هذا الدليل التقني الشامل تحليلاً مفصلاً للبنية التحتية للشبكات التي تجعل تهريب الطلبات ممكناً، ويشرح بدقة آليات الاختلال التقليدية CL.TE وTE.CL، ويستكشف هجمات تخفيض بروتوكول HTTP/2 المتقدمة (H2.CL وH2.TE)، ويعرض سيناريوهات استغلال واقعية، إضافة إلى استراتيجيات الدفاع والتقسية الهندسية الصارمة لتأمين البنية التحتية.

---

١. المعمارية الهندسية لتهريب طلبات HTTP

نادراً ما تعتمد البنى التحتية الحديثة لتطبيقات الويب على ربط الخوادم الخلفية مباشرة بشبكة الإنترنت العامة. وبدلاً من ذلك، تعتمد المعماريات ذات الكفاءة العالية على توجيه الزيارات عبر خوادم البروكسي العكسي وشبكات توزيع المحتوى (CDNs) مثل Cloudflare وAWS Application Load Balancers (ALB) وFastly وNginx وHAProxy وEnvoy. تؤدي هذه الأجهزة الطرفية أدواراً حيوية تشمل: إنهاء تشفير TLS، وتوجيه المسارات، والتخزين المؤقت، وتحديد معدل الطلبات، والتفتيش الأمني عبر WAF.

لتحقيق أقصى قدر من الأداء الشبكي وتقليل زمن الاستجابة، تقوم خوادم البروكسي بتجميع ومضاعفة (Multiplexing) طلبات العملاء المتعددة عبر اتصالات TCP مستمرة ومستقرة (Persistent Connections) مع خوادم الواجهة الخلفية. إن إنشاء اتصال TCP جديد في كل مرة يتطلب مصافحة ثلاثية وتخصيص موارد للمقبس وتفاوض TLS، بينما يسمح الإبقاء على الاتصال مفتوحاً (HTTP/1.1 Keep-Alive) للبروكسي بتمرير مئات الطلبات من مستخدمين مختلفين عبر اتصال شبكي واحد.

+------------------+        HTTP/1.1 أو HTTP/2
| المستخدم الشرعي  | -------------------------\
+------------------+                           \   +----------------------+   اتصال TCP مستمر ومشترك  +-----------------------+
                                                ==>|  خادم البروكسي       |==========================>|  خادم التطبيق الخلفي   |
+------------------+                           /   |  (Cloudflare / ALB)  |   (طلبات متتالية Pipelined)|  (Node.js / Tomcat)   |
| المهاجم          | -------------------------/    +----------------------+                           +-----------------------+
+------------------+

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

نظراً لأن بروتوكول HTTP/1.1 هو تدفق نصي مفتوح، تعتمد برمجيات التحليل (Parsers) حصرياً على البيانات الوصفية في الترويسات (Headers) لحساب حجم جسم الطلب (Body Length). فإذا اختلف خادم الواجهة الأمامية وخادم الواجهة الخلفية في كيفية تفسير هذه الترويسات، يحدث اختلال التزامن (Desynchronization). ترسل الواجهة الأمامية ما تعتبره طلباً واحداً، بينما يقوم خادم الواجهة الخلفية بتجزئة سيل البايتات إلى طلبين منفصلين؛ وتبقى البايتات الإضافية عالقة في ذاكرة القراءة المؤقتة، لتبدأ بها معالجة أول طلب يصل بعدها على نفس المسار المشترك.

---

٢. تعارض معيار RFC 7230: Content-Length مقابل Transfer-Encoding

في مواصفات بروتوكول HTTP/1.1، هناك آليتان معتمدتان لتحديد حجم وحدود جسم الطلب:

• Content-Length (CL): ترويسة تحدد الطول الدقيق لجسم الرسالة بالبايتات كرقم عشري. يقرأ المحلل هذا العدد المحدد تماماً من البايتات بعد سطر الفراغ المزدوج (\r\n\r\n).
• Transfer-Encoding: chunked (TE): آلية تُرسل بموجبها بيانات الجسم كأجزاء متتابعة (Chunks). تبدأ كل كتلة بحجمها بنظام العد السداسي عشري، متبوعاً بـ \r\n، ثم محتوى الكتلة، ثم \r\n أخرى. وينتهي التدفق بكتلة صفرية: 0\r\n\r\n.

ماذا يحدث إذا تضمن طلب HTTP واحد كلا الترويستين معاً؟

لقد تنبأت مجموعة IETF بهذا التعارض بدقة، حيث تنص الفقرة 3.3.3 من مواصفة RFC 7230 على القاعدة المعيارية الصريحة:

"إذا استُلمت رسالة تحتوي على كل من حقل الترويسة Transfer-Encoding وحقل الترويسة Content-Length، فيجب إزالة أو تجاهل Content-Length؛ وتكون الأولوية دائماً لـ Transfer-Encoding."

في بيئة مثالية تلتزم بالمعايير بدقة، ستمنح جميع الأنظمة الأولوية لـ Transfer-Encoding: chunked وتتجاهل Content-Length. ولكن في الواقع العملي، تظهر اختلافات شائعة في التطبيق:

• بعض خوادم البروكسي القديمة لا تدعم التشفير المجزأ (chunked) في الطلبات الواردة، فتعتمد تلقائياً على Content-Length.
• بعض خوادم الويب الخلفية تعطي الأسبقية لـ Content-Length عندما تلاحظ أي صياغة غير معتادة لترويسة Transfer-Encoding.
• تقوم بعض أجهزة التفتيش الأمنية بتنقيح إحدى الترويستين وتمرير الأخرى دون تعديل.

عندما تشتمل البنية التحتية على خادمين يتخذان قرارين متضادين حيال نفس الطلب، يصبح النظام معرضاً بشكل مباشر لثغرة تهريب طلبات HTTP.

---

٣. ثغرة CL.TE: الواجهة الأمامية تعتمد CL والواجهة الخلفية تعتمد TE

في سيناريو اختلال التزامن CL.TE، يعالج خادم البروكسي الأمامي الطلب بالاعتماد على ترويسة Content-Length، بينما يعالج خادم التطبيق الخلفي الطلب وفق ترويسة Transfer-Encoding: chunked.

تشريح حمولة CL.TE

إليك نموذجاً لطلب HTTP الخام الذي يرسله المهاجم إلى البروكسي:

POST / HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
Content-Length: 13\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\n
\r\n
SMUGGLED

آلية التنفيذ خطوة بخطوة

1. المعالجة في الواجهة الأمامية: يفحص خادم البروكسي ترويسة Content-Length: 13، ويعد 13 بايتاً ابتداءً من جسم الطلب:
   0\r\n (3 بايتات) + \r\n (بايتان) + SMUGGLED (8 بايتات) = 13 بايتاً.
   يستنتج البروكسي أن جسم الطلب اكتمل بالكامل، وبما أنه يثق بـ Content-Length، فإنه يعيد توجيه الـ 13 بايتاً كاملة إلى الخادم الخلفي عبر اتصال TCP المشترك.
2. المعالجة في الواجهة الخلفية: يطبق الخادم الخلفي معيار RFC 7230 ويعطي الأولوية لـ Transfer-Encoding: chunked. يبدأ بقراءة التدفق المجزأ.
   يصادف الخادم أولاً 0\r\n متبوعاً بسطر فارغ \r\n، وهو ما يمثل الإشارة الرسمية لنهاية البيانات المجزأة.
   يعتبر الخادم الخلفي أن الطلب الحالي قد انتهى فوراً، ويبدأ بتنفيذ التعليمات البرمجية للطلب ويرسل استجابته إلى الواجهة الأمامية.
3. حالة مقبس الشبكة بعد الاختلال: ماذا حل بالـ 8 بايتات المتبقية (SMUGGLED)؟
   لم يقم الخادم الخلفي بقراءتها إطلاقاً، وظلت معلقة في ذاكرة التخزين المؤقت لمقبس TCP في انتظار الطلب التالي.
4. تخريب طلب الضحية: بعد لحظات، يرسل مستخدم شرعي طلباً عادياً عبر نفس اتصال TCP المشترك:

   GET /profile HTTP/1.1\r\n
   Host: vulnerable-website.com\r\n
   User-Agent: Mozilla/5.0...\r\n
   ...

   يقرأ الخادم الخلفي البيانات من المقبس فيجد البايتات العالقة في مقدمة الطلب:

   SMUGGLEDGET /profile HTTP/1.1\r\n
   Host: vulnerable-website.com\r\n
   User-Agent: Mozilla/5.0...\r\n
   ...

   يفشل الخادم الخلفي في التعرف على الطريقة SMUGGLEDGET ويعيد خطأ 400 Bad Request أو ينفذ طلباً مخصصاً إذا تمكن المهاجم من صياغة بادئة متكاملة.

---

٤. ثغرة TE.CL: الواجهة الأمامية تعتمد TE والواجهة الخلفية تعتمد CL

في حالة اختلال TE.CL، تنعكس الأدوار تماماً. يثق البروكسي الأمامي بترويسة Transfer-Encoding: chunked، بينما يتجاهلها الخادم الخلفي تماماً ويعتمد حصرياً على Content-Length.

تشريح حمولة TE.CL

يبني المهاجم طلباً يمتد فيه التدفق المجزأ إلى ما بعد الحجم المعلن في Content-Length:

POST / HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
Content-Length: 3\r\n
Transfer-Encoding: chunked\r\n
\r\n
8\r\n
SMUGGLED\r\n
0\r\n
\r\n

آلية التنفيذ خطوة بخطوة

1. المعالجة في الواجهة الأمامية: يعتمد البروكسي ترويسة Transfer-Encoding: chunked. يقرأ حجم الكتلة الأولى 8، ويستهلك 8 بايتات (SMUGGLED)، ثم يقرأ \r\n، ويقرأ حجم الكتلة الصفرية 0 متبوعاً بـ \r\n.
   يرى البروكسي أن التدفق المجزأ سليم ومكتمل، فيقوم بإرسال الطلب بالكامل إلى الخادم الخلفي.
2. المعالجة في الواجهة الخلفية: يقرأ الخادم الخلفي 3 بايتات فقط وفقاً لـ Content-Length: 3، وهي تمثل: 8\r\n.
   يعتبر الخادم الخلفي الطلب منتهياً، ويعالجه ويرسل استجابته إلى البروكسي.
3. حالة مقبس الشبكة: تظل البايتات المتبقية—SMUGGLED\r\n0\r\n\r\n—علقة داخل ذاكرة مقبس TCP الخلفي دون قراءة.
4. دمج طلب الضحية بالطلب المهرب: عند وصول الطلب التالي من أي مستخدم آخر:

   GET /search?q=test HTTP/1.1\r\n
   Host: vulnerable-website.com\r\n
   ...

   يبدأ الخادم الخلفي القراءة انطلاقاً من البايتات المهربة:

   SMUGGLED\r\n
   0\r\n
   \r\n
   GET /search?q=test HTTP/1.1\r\n
   Host: vulnerable-website.com\r\n
   ...

   إذا استبدل المهاجم كلمة SMUGGLED بطلب HTTP كامل مثل GET /admin HTTP/1.1\r\nHost: vulnerable-website.com\r\n...، فإن الخادم ينفذ الطلب الإداري المهرب داخل النطاق الداخلي الموثوق.

تقنيات التمويه في ثغرات TE.TE

عندما يدعم كلا الخادمين ترويسة Transfer-Encoding، لا يزال بإمكان المهاجم إحداث الاختلال إذا تمكن من خداع أحد الخادمين ليتجاهل الترويسة عبر التلاعب بالمسافات أو الأحرف غير القياسية:

Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: cow
Transfer-Encoding:[tab]chunked
X: X[\n]Transfer-Encoding: chunked

إذا تغاضى البروكسي عن التمويه وعالج الطلب كتدفق مجزأ، بينما رفضه الخادم الخلفي وعاد للاعتماد على Content-Length، تنشأ ثغرة TE.CL كاملة الفعالية.

---

٥. هجمات تخفيض بروتوكول HTTP/2: ناقلات H2.CL وH2.TE

مع الانتشار الواسع لبروتوكول HTTP/2، اعتقد العديد من المطورين أن هجمات تهريب الطلبات قد انتهت إلى الأبد. ففي الإصدار الأصيل من HTTP/2، تُرسل البيانات في هيئة أطر ثنائية (Binary Frames)، ويحتوي كل إطار بيانات DATA على حقل طول صريح ومحدد بدقة (24 بت) في ترويسة الإطار المكونة من 9 بايتات. نظراً لأن حدود الرسائل محددة على مستوى طبقة النقل، يستحيل حدوث غموض نصي داخل شبكة تعتمد HTTP/2 الخالص.

ومع ذلك، أفرزت المعماريات الحديثة خللاً تصميمياً قاتلاً: تخفيض البروتوكول (HTTP/2 Downgrading من الواجهة الأمامية إلى HTTP/1.1 في الواجهة الخلفية).

+------------------+      HTTP/2 (أطر ثنائية محكمة)   +----------------------+      HTTP/1.1 (تدفق نصي تقليدي)       +-----------------------+
| جهاز المهاجم     | ===============================>|  بروكسي الواجهة      | =====================================> |  خادم التطبيق الخلفي   |
| (Burp Suite /    |   - أطوال أطر واضحة             |  الأمامية             |   - تحليل CL و TE النصي                |  (أنظمة سابقة)        |
|  h2load)         |   - إمكانية حقن ترويسات         |  (تحويل H2 إلى H1.1)  |   - عرضة لاختلال التزامن              |                       |
+------------------+                                 +----------------------+                                        +-----------------------+

تستقبل خوادم البروكسي اتصالات المستخدمين عبر HTTP/2 لتحسين السرعة على الأجهزة المحمولة، لكنها تحول تلك الطلبات إلى HTTP/1.1 عند تمريرها إلى الخدمات المصغرة الداخلية. أثبتت أبحاث جيمس كيتل أن عملية التحويل هذه تفتح أبواباً لثغرات خطيرة.

هجمات H2.CL (حقن Content-Length عبر HTTP/2)

في بروتوكول HTTP/2 الخالص، تُعد ترويسة content-length زائدة عن الحاجة لأن حدود الأطر معروفة. إلا أن مواصفة RFC 7540 تسمح للعميل بإرسالها بشرط أن تطابق الطول الفعلي للبيانات.

إذا أخفق البروكسي في التحقق من تطابق قيمة content-length مع حجم الأطر الحقيقي، يمكن للمهاجم إرسال طلب HTTP/2 بقيمة طول خاطئة عمداً:

:method: POST
:path: /
:authority: target.com
content-length: 0

SMUGGLED REQUEST BODY

عندما يخفض البروكسي هذا الطلب إلى HTTP/1.1، يُصدر النص التالي:

POST / HTTP/1.1\r\n
Host: target.com\r\n
Content-Length: 0\r\n
\r\n
SMUGGLED REQUEST BODY

يقرأ الخادم الخلفي Content-Length: 0، ويعتبر الطلب منتهياً فوراً، تاركاً محتوى الجسم المهرب كبيانات معلقة في اتصال TCP لتصطدم بالطلب التالي.

هجمات H2.TE (حقن Transfer-Encoding عبر HTTP/2)

تنص الفقرة 8.1.2.2 من RFC 7540 على حظر ترويسات الاتصال في HTTP/2، لا سيما Transfer-Encoding، وتوجب رفض أي طلب يتضمنها بإرجاع خطأ PROTOCOL_ERROR.

وعلى الرغم من ذلك، تقوم عدة خوادم بروكسي بتمرير ترويسة transfer-encoding: chunked دون تنقية عند التخفيض إلى HTTP/1.1، مما يدفع الخادم الخلفي لقراءة الجسم كتدفق مجزأ، مسبباً اختلالاً فورياً في التزامن.

حقن CRLF في ترويسات HTTP/2

نظراً لأن ترويسات HTTP/2 تُشفر كأزواج مفاتيح وقيم ثنائية عبر HPACK دون استخدام محارف \r\n للفصل، يمكن لقيم الترويسات أن تتضمن محارف رجوع السطر وتغذية السطر (CRLF) دون أن يتعطل الإطار الثنائي.

إذا لم يقم البروكسي بفلترة هذه المحارف عند التخفيض إلى HTTP/1.1، يمكن للمهاجم حقن ترويسات جديدة أو جسم طلب كامل داخل قيمة ترويسة واحدة:

اسم الترويسة : foo
قيمة الترويسة: bar\r\n\r\nGET /admin HTTP/1.1\r\nHost: target.com\r\n\r\n

عند التحويل إلى HTTP/1.1، تُترجم الفواصل السطرية حرفياً، مما يؤدي إلى شطر الطلب ودس الطلب الإداري مباشرة في مجرى الاتصال الخلفي.

---

٦. سيناريوهات استغلال واقعية

لا يقتصر تهريب الطلبات على العبث بالبروتوكول، بل يمثل نقطة انطلاق قوية لتنفيذ هجمات خطيرة على التطبيقات والبيانات.

السيناريو أ: تجاوز ضوابط الوصول في الواجهة الأمامية

غالباً ما تفرض خوادم البروكسي قيوداً أمنية تمنع الوصول إلى المسارات الإدارية الحساسة (مثل /admin) لغير عناوين IP المصرح لها داخلياً.

عند تهريب طلب GET /admin HTTP/1.1 خلف طلب عام مشروع (مثل POST /search)، يتجاوز الطلب المهرب جميع مرشحات التوجيه في الواجهة الأمامية. يستقبل الخادم الخلفي الطلب عبر الاتصال الداخلي الموثوق ويعالجه بصلاحيات كاملة. كما يستطيع المهاجم حقن ترويسات ثقة داخلية مباشرة مثل X-Forwarded-For: 127.0.0.1 أو X-Admin-Role: true.

السيناريو ب: اختطاف الطلبات وسرقة بيانات الاعتماد

يمكن للمهاجم تهريب طلب غير مكتمل ومصمم لابتلاع طلب المستخدم التالي واحتوائه:

POST /submit-comment HTTP/1.1\r\n
Host: target.com\r\n
Content-Length: 1000\r\n
Cookie: attacker_session=xyz\r\n
\r\n
comment=

عندما يرسل المستخدم التالي طلبه:

GET /account HTTP/1.1\r\n
Host: target.com\r\n
Authorization: Bearer secret_jwt_token_here\r\n
Cookie: session=victim_active_session_id\r\n
\r\n

يدمج الخادم الخلفي طلب الضحية داخل حقل التعليق comment= حتى استيفاء الطول المعلن (1000 بايت). وبذلك تُحفظ رموز الجلسات وترويسات التفويض الخاصة بالضحية في قاعدة البيانات وتظهر علناً في صفحة التعليقات الخاصة بالمهاجم.

السيناريو ج: تسميم الذاكرة المؤقتة للويب (Web Cache Poisoning)

إذا كانت الواجهة الأمامية مزودة بطبقة كاش (Cache)، يتيح تهريب الطلبات تسميم الذاكرة المؤقتة للملفات الثابتة لجميع زوار الموقع دون استثناء.

يقوم المهاجم بتهريب طلب إعادة توجيه (302 Redirect) إلى خادم خبيث قبل طلب ملف جافاسكريبت رئيسي (مثل /static/bundle.js). يقوم البروكسي بربط استجابة إعادة التوجيه بعنوان الملف المذكور في الكاش. وخلال كامل فترة بقاء الكاش (TTL)، يستقبل كل زائر يحمل ملف الجافاسكريبت الرابط الخبيث للمهاجم، مما يؤدي إلى هجمات XSS شاملة واختطاف لحسابات المستخدمين على نطاق واسع.

السيناريو د: تضخيم ثغرات XSS المنعكسة (بدون نقر - Zero-Click)

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

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

---

٧. استراتيجيات الدفاع والتقسية الهندسية

تتطلب الحماية الفعالة ضد هجمات تهريب طلبات HTTP إدخال تعديلات جوهرية على إعدادات البروكسي وخوادم التطبيقات الخلفية معاً.

١. تطبيق بروتوكول HTTP/2 أو HTTP/3 من البداية إلى النهاية

يعد التخلص من تخفيض البروتوكول (Downgrading) الحل المعماري الأكثر أماناً واستدامة. احرص على أن تتواصل خوادم البروكسي مع الخوادم الخلفية عبر بروتوكول HTTP/2 أو HTTP/3 الخالص مباشرة. فعندما تُحفظ الأطر الثنائية عبر كامل المسار، ينتفي أي لبس في تفسير أطوال الرسائل.

٢. فرض الالتزام الصارم بمعيار RFC 9112

تنص مواصفة RFC 9112 الفقرة 6.1 صراحة على ما يلي:

• إذا احتوى الطلب على كل من Content-Length وTransfer-Encoding، يجب على الخادم أو البروكسي رفض الطلب فوراً بإرجاع الخطأ 400 Bad Request.
• يُحظر تماماً محاولة معالجة الترويستين أو ترجيح إحداهما عند وجودهما معاً. إن إسقاط الطلبات المتناقضة يجهض محاولات الاختلال قبل بدئها.

٣. ضبط وتقسية خوادم الويب وموازنات الأحمال

خوادم Nginx: تأكد من استخدام الإصدارات الحديثة (1.21.1 فما فوق) التي ترفض الطلبات المتناقضة، مع تفعيل الخيارات الصارمة التالية:

# تفعيل التدقيق الصارم لترويسات HTTP
ignore_invalid_headers on;
underscores_in_headers off;

# إعدادات البروكسي العكسي
proxy_http_version 1.1;
proxy_set_header Connection "";

خوادم AWS Application Load Balancer (ALB): من خلال خصائص موازن الأحمال، قم بضبط وضع HTTP Desync Mitigation Mode على Defensive أو Strictest:

• Monitor: يسجل الأنشطة المريبة دون حظرها (غير آمن).
• Defensive: يسمح بالطلبات المتوافقة ويحظر الطلبات الغامضة والمخالفة للمواصفات.
• Strictest: يفرض الالتزام الكامل بمعايير RFC 7230 وRFC 9112 ويسقط أي طلب يتضمن أدنى التباس.

٤. تعطيل إعادة استخدام اتصالات TCP في الواجهة الخلفية

إذا كانت هناك خوادم خلفية قديمة لا يمكن تحديثها لمعالجة التناقضات، قم بإلغاء تجميع اتصالات TCP بين البروكسي والخوادم الخلفية. إن إنشاء اتصال TCP مخصص ومستقل لكل طلب عميل يلغي وجود الذاكرة المؤقتة المشتركة، مما يجعل تهريب الطلبات بين المستخدمين مستحيلاً من الناحية الفيزيائية.

٥. تفعيل قواعد جدران الحماية المتقدمة (WAF)

قم بتهيئة جدار حماية تطبيقات الويب على الأطراف لفحص التدفقات ورفض الآتي فوراً:

• أي طلب يتضمن في Transfer-Encoding قيماً بخلاف chunked.
• الطلبات التي تحتوي على مسافات أو فراغات قبل النقطتين الرأسيتين في الترويسات.
• الطلبات التي تحتوي على ترويسات مكررة أو متناقضة.
• طلبات HTTP/2 التي تتضمن ترويسات محظورة مثل (transfer-encoding وconnection وkeep-alive).

---

خلاصة

تكشف هجمات تهريب طلبات HTTP عن المخاطر الجسيمة الناجمة عن تباين البرمجيات والمحللات عند تكديس البروتوكولات عبر بيئات البنية التحتية الموزعة. ومع التوسع في تبني HTTP/2 وHTTP/3 جنباً إلى جنب مع خدمات مصغرة تعتمد على بروتوكولات أقدم، تظل نقاط التحويل البروتوكولي هدفاً رئيسياً للمهاجمين. إن إجراء فحوصات وتدقيقات أمنية عميقة وتطبيق معايير RFC 9112 بصرامة يمثلان خط الدفاع الأساسي لحماية التطبيقات وسلامة بيانات المستخدمين.