Benoit Chesneau

توجد مشكلة تقسيم طلب HTTP (HTTP Request Splitting) في `hackney http connect` بسبب عدم تحييد تسلسلات CRLF بشكل صحيح في ترويسات HTTP. عندما يقوم بروكسي HTTP CONNECT بإرجاع استجابة 407، تقوم الدالة `hackney http connect:handle proxy auth/11` بتنفيذ استدعاء `proxy auth fun` وكتابة البيانات الثنائية المسترجعة مباشرة في سطر `Proxy-Authorization` لطلب إعادة المحاولة دون التحقق منها. إذا كانت القيمة المسترجعة تحتوي على إرجاع العربة (CR)، أو تغذية السطر (LF)، أو بايت NUL، يمكن للمهاجم إضافة أسطر ترويسة إضافية إلى الطلب المرسل إلى البروكسي. يحدث هذا عندما يشتق الاستدعاء قيمته من بيانات غير موثوقة، مثل ترويسات التحدي الخاصة بالبروكسي.

توجد ثغرة تسمح لخادم إعادة التوجيه بالحصول على بيانات اعتماد `basic auth` و `cookie` من خلال إعادة توجيه على نفس المضيف إلى مخطط أو منفذ مختلف. عند تمكين `follow redirect` تقوم الدالة `hackney:follow redirect/10` في `src/hackney.erl` بإعادة إرسال الطلبات إلى هدف `Location`. تقوم عملية التحقق التي تجريها `hackney:maybe strip auth on redirect/3` بمقارنة اسم المضيف فقط بين URL الحالي وURL إعادة التوجيه. وبناءً على ذلك، فإن إعادة التوجيه من `https` إلى `http` على نفس المضيف ترسل ترويسات `Authorization` و `Cookie` بنص واضح، مما يسمح للمهاجم الموجود على المسار باعتراضها. وبالمثل، فإن إعادة التوجيه إلى منفذ مختلف على نفس المضيف ترسل بيانات الاعتماد هذه إلى خدمة مختلفة. يحدث هذا عبر HTTP/1.1 و HTTP/2 عندما لا يكون `location trusted` مفعلًا.

يسمح تعارض في التفسير في `hackney url` بتنفيذ هجوم تزوير الطلبات عبر الخادم (SSRF). يحدث هذا عندما يتم تقديم المضيف كعنوان IPv6 حرفي بين أقواس مشفر بنسبة مئوية أو عنوان IP حرفي ينتهي بنقطة. بينما قد لا تتعرف قائمة السماح الخاصة بالمستدعي التي تستخدم `uri string:parse/1` و `inet:parse address/1` على هذه القيم كعناوين IP، فإن hackney يتصل بالعنوان المشار إليه. ينطبق الأمر نفسه على أهداف `Location` عند اتباع عمليات إعادة التوجيه. تنبع المشكلة من قيام `hackney url:normalize/2` بتمرير القيم التي تم فك تشفيرها إلى `inet parse:address/1` كما هي، بينما يقوم مسار الاتصال في `hackney happy:parse address/1` بإسقاط الأقواس المحيطة ويتجاهل الموجه النقطة النهائية، مما يسمح لهذه الأشكال بتجاوز بوابة العنوان الحرفي. التطبيقات التي تستخدم قائمة سماح لعناوين IP لمنع الطلبات إلى العناوين الداخلية، مثل loopback أو بيانات وصفية للارتباط المحلي، تكون عرضة لهذا الخطر.

توجد مشكلة في تخصيص الموارد في `hackney conn` تسمح لخادم HTTP ضار باستنفاد ذاكرة العميل عن طريق إرسال جسم استجابة ضخم أو مضغوط للغاية. تقوم الدوال `hackney:request/5` و `hackney:body/1` بإرجاع جسم الاستجابة بالكامل دون وجود حدود لكمية البيانات التي يتم تخزينها مؤقتًا في عملية الاتصال. وبشكل محدد، تقوم `hackney conn:read full body/2` ومراكمات HTTP/2 و HTTP/3 بإضافة كل جزء حتى ينتهي الجسم. عند استخدام خيار `{auto decompress, true}`، يتم تضخيم الجسم المخزن مؤقتًا في خطوة واحدة باستخدام `zlib:gunzip/1` أو `zlib:inflate/2` والتي تعيد المخرجات كاملة دفعة واحدة. يمكن أن يؤدي ذلك إلى تضخيم كبير في استهلاك الذاكرة؛ على سبيل المثال، يمكن أن يتضخم جسم gzip بحجم 1 ميجابايت إلى 1 جيجابايت.

توجد حلقة لا نهائية في محلل رأس استجابة Alt-Svc داخل `src/hackney altsvc.erl`. عندما تتلقى الدالة `parse token/2` بايتًا ليس رمزًا أو مسافة بيضاء أو فاصلة (مثل ! أو @ أو = أو ;)، فإنها تُرجع المدخلات دون تغيير. وبالمثل، تُرجع الدالة `skip comma/1` المخزن المؤقت دون تغيير إذا لم يكن البايت الأول فاصلة. يؤدي هذا إلى تكرار الدالة `parse entries/2` باستخدام بيانات متطابقة، مما يخلق حلقة تكرارية ذيلية لانهائية محكمة تستهلك 100% من جدولة وحدة المعالجة المركزية (CPU) وتمنع العملية المستدعية من العودة. يتم استدعاء نقطة الدخول `parse and cache/3` بشكل متزامن خلال كل استجابة HTTP، مما يعني أن رأس استجابة `Alt-Svc: !` المكون من بايت واحد من أي مصدر HTTP يمكن أن يؤدي إلى تعطل النظام.

تسمح مشكلة في محلل عناوين URL الموجود في ملف `src/hackney url.erl` باستنفاد الموارد. يستخدم المحلل الدالة `binary to atom/2` لتحويل أنظمة عناوين URL غير المعترف بها إلى ذرات BEAM دائمة. ونظرًا لأن ذرات BEAM لا تخضع لعملية جمع القمامة (garbage collection) ولأن جدول الذرات له حد أقصى ثابت يبلغ 1,048,576 إدخالًا، يمكن للمهاجم استنفاد هذا الجدول عن طريق تقديم عناوين URL ذات بادئات أنظمة مخصصة. ويمكن تحقيق ذلك من خلال أهداف الطلبات، أو عناوين URL المُعدة مسبقًا لـ webhooks، أو رؤوس Location أثناء عمليات إعادة التوجيه، مما يؤدي إلى تعطل آلة BEAM الافتراضية (BEAM VM) بالكامل مع ظهور خطأ `system limit`.

يؤدي التعطيل غير السليم لتسلسلات CRLF، المعروف أيضًا باسم حقن CRLF، إلى السماح بتقسيم استجابة HTTP. تقوم الدالة `setcookie/3` الموجودة في `src/hackney cookie.erl` بالتحقق من صحة حجتي الاسم والقيمة مقابل CRLF وأحرف التحكم، ولكنها تربط خيارات المجال والمسار في قائمة iolist الناتجة دون إجراء فحوصات مماثلة. يمكن للمهاجم الذي يتحكم في هذه الخيارات، مثل تقديم قيمة رأس Host كنطاق ملف تعريف الارتباط أو مسار الطلب كمسار ملف تعريف الارتباط، حقن تسلسلات CRLF حرفية ورؤوس Set-Cookie إضافية عشوائية في استجابة HTTP.

توجد مشكلة تتعلق بتسرب البيانات الحساسة، حيث يقوم معالج إعادة التوجيه HTTP/3 الموجود في `src/hackney h3.erl` بتمرير رؤوس الطلب الأصلية إلى هدف إعادة التوجيه دون إجراء فحوصات عبر الأصول. إذا أرسل عميل طلب HTTP/3 مع تمكين `follow redirect` وتضمن رؤوس `Authorization` أو `Cookie`، فإن استجابة الخادم بإعادة توجيه 3xx إلى مضيف مختلف ستؤدي إلى قيام العميل بإعادة توجيه بيانات الاعتماد هذه حرفياً إلى المنشأ الجديد. يحدث هذا لأن ملف `hackney h3.erl` يفتقر إلى الحماية التي توفرها الدالة `maybe strip auth on redirect()` الموجودة في الوحدة النمطية الرئيسية `hackney.erl`.

يؤدي الاستهلاك غير المنضبط للموارد في نقل SOCKS5 داخل `src/hackney socks5.erl` إلى حدوث إغراق. في حين يتم تطبيق مهلة الانتظار التي يحددها المتصل خلال مرحلة التفاوض SOCKS5، فإن ترقية الاتصال إلى TLS عبر الدالة `ssl:connect/2` تعود افتراضيًا إلى مهلة انتظار لا نهائية لأن المتغير `Timeout` لا يتم توجيهه. ونتيجة لذلك، يمكن لبروكسي SOCKS5 ضار يُكمل عملية المصافحة ثم يتوقف أو يرسل TLS ServerHello جزئيًا أن يتسبب في تعطل عملية الاتصال إلى أجل غير مسمى، متجاهلًا خيارات `connect timeout` أو `recv timeout`.

يؤدي التعطيل غير السليم لتسلسلات CRLF، والمعروف أيضًا باسم «حقن CRLF»، إلى السماح بتقسيم طلبات/استجابات HTTP. يقوم كود ترقية WebSocket الموجود في `src/hackney ws.erl` بنسخ خيارات المضيف والمسار والرؤوس (`ExtraHeaders`) والبروتوكولات من خريطة الخيارات التي يوفرها المستدعي إلى السجل الداخلي `#ws data{}` في `init/1`، ثم يدمجها حرفياً في طلب الترقية الخام لـ HTTP/1.1 عن طريق التسلسل الثنائي في `do handshake/1`. ونظرًا لعدم إجراء أي إزالة لـ CRLF أو NUL في مواقع الإدخال الأربعة هذه، يمكن للمهاجم الذي يتحكم في هذه الخيارات — مثل إعادة توجيه مكونات URL أو قيم الرؤوس من مدخلات غير موثوق بها إلى `hackney ws:start link/1` — إدخال رؤوس HTTP تعسفية في طلب ترقية WebSocket الصادر. ويمكن أن يؤدي ذلك إلى حقن الرؤوس، أو انتحال بيانات الاعتماد تجاه الخادم الأعلى، أو تسميم السجلات وذاكرة التخزين المؤقت، أو تهريب الطلبات عبر بروكسيات وسيطة.

يفتقر عميل WebSocket الموجود في `src/hackney ws.erl` إلى حدود قصوى لاستهلاك الذاكرة عبر ثلاثة مسارات برمجية، مما يسمح بحدوث إغراق. أولاً، تقوم الدالة `read handshake response/3` بتجميع البايتات المستلمة في مخزن مؤقت دون حد أقصى للحجم؛ ويؤدي قيام الخادم ببث البايتات دون تسلسل الإنهاء المطلوب إلى تزايد حجم المخزن المؤقت حتى نفاد الذاكرة. ثانيًا، لا تقوم الدالتان `parse payload/9` و`parse active payload/8` بالتحقق من صحة أطوال حمولة الإطارات المعلنة، والتي يمكن أن تصل إلى 2^63-1 بايت وفقًا لمعيار RFC 6455، مما يؤدي إلى حالات نفاد الذاكرة (OOM) عندما يعلن الخادم عن إطار كبير جدًّا. ثالثًا، يقوم حقل `frag buffer` في `#ws data{}` بتجميع إطارات المتابعة إلى ما لا نهاية إذا أرسل الخادم دفقًا من الإطارات المجزأة غير النهائية دون إطار نهائي. لا يحتاج المهاجم سوى إلى التحكم في خادم WebSocket الذي يتصل به العميل، دون الحاجة إلى مصادقة أو تكوين خاص.

يؤدي التعطيل غير السليم لتسلسلات CRLF إلى السماح بتقسيم طلبات HTTP. يفشل البرنامج في ترميز أحرف العودة إلى السطر (`r`) أو التقدم إلى السطر التالي (` `) بنسبة مئوية في مكون استعلام URL قبل إنشاء هدف طلب HTTP/1.1. وعلى وجه التحديد، تقوم الدالة `hackney url:make url/3` بتمرير البيانات الثنائية للاستعلام مباشرةً دون التحقق من صحتها أو إخضاعها لعملية الهروب، مما يشكل انتهاكًا للمادة 3.4 من RFC 3986. يمكن للمهاجم الذي يتحكم في جزء من عنوان URL حقن تسلسلات CRLF الخام في سلسلة الاستعلام، مما يتيح حقن رؤوس HTTP تعسفية أو تقسيم طلب HTTP.

يؤدي تعارض في التفسير إلى حدوث تزوير الطلبات من جانب الخادم (SSRF)، وهو عيب يتيح للمهاجم حث الخادم على إرسال طلبات إلى موقع غير مقصود. تقوم الدالة `hackney url:normalize/2` بفك تشفير مكون المضيف بعد تحليل عنوان URL وتحويله إلى سجل `#hackney url{}`. ونظرًا لأن دالتَي OTP `uri string:parse/1` و`inet:parse address/1` لا تقومان بفك تشفير رموز الهروب المئوية في المضيف، فإن عنوان URL الذي يحتوي على أحرف مشفرة بنسبة مئوية يمكنه تجاوز أدوات التحقق من قائمة السماح التي لا تتعرف على السلسلة المشفرة كعنوان IP. وبالتالي، يقوم أداة التوحيد بفك تشفير المضيف (على سبيل المثال، تحويل `%31%32%37%2E%30%2E%30%2E%31` إلى `127.0.0.1`)، مما يتيح اتصالات TCP بواجهة loopback، وخدمات بيانات تعريف مثيلات السحابة (169.254.169.254)، وشبكات RFC1918، وواجهات الإدارة المحلية. ويحدث هذا لأن `hackney:request/5` تستدعي دائمًا `hackney url:normalize/2` دون آلية استثناء للطلبات التي تستخدم عناوين URL ثنائية أو قائمة.

يؤدي تخصيص الموارد دون حدود أو تقييد إلى حدوث إغراق. تقوم الدالة `await response loop/6` في `hackney h3` بتجميع نص استجابة HTTP/3 في الذاكرة دون حد أقصى للحجم. ونظرًا لأن بند المهلة يعمل كمؤقت لعدم النشاط لكل رسالة يتم إعادة ضبطه عند استلام أجزاء أو رسائل صيانة أو إطارات إعدادات بدلاً من موعد نهائي ثابت، يمكن لخادم HTTP/3 ضار أن يبقي الحلقة نشطة إلى أجل غير مسمى. من خلال إرسال أجزاء صغيرة قبل انتهاء مهلة الانتظار مباشرةً مع تعيين `Fin` على false وحذف الإطار النهائي، يتسبب الخادم في نمو مخزن التراكم بشكل خطي، مما يستنفد كومة عملية BEAM ويؤدي إلى حالة نفاد الذاكرة. تحدث هذه المشكلة عندما يستخدم التطبيق بروتوكول النقل HTTP/3 عبر `hackney h3` أو عن طريق تمرير `{transport, h3}` إلى `hackney:request/5`.