Martin Karrer

يسمح التحقق غير السليم من الشهادات التي تعاني من عدم تطابق المضيف للمهاجم في المنتصف بانتحال صفة نظير TLS عبر شهادة تحمل علامة نجمية (wildcard) جزئية. تقوم الدالة `try match wildcard/4` في `src/ssl verify hostname.erl` بتثبيت النص قبل وبعد علامة النجمة فقط في المعرفات مثل `f*.example.net` ، مما يسمح للعلامة النجمية باستهلاك النقاط وقبول الشهادة لنطاقات غير مصرح بها مثل `f.evil.example.net`. وهذا يتعارض مع RFC 6125 التي تحصر العلامة النجمية في التسمية الموجودة في أقصى اليسار. بالإضافة إلى ذلك، يسمح المطابق لـ `*.168.1.1` بمطابقة العنوان الرقمي `192.168.1.1`. تؤثر هذه المشكلة على العملاء الذين يعطلون مؤشر اسم الخادم (SNI)، والخوادم التي تتحقق من أسماء مضيف شهادات العميل، والمستدعين المباشرين للدالة `verify cert hostname/2`.

توجد ثغرة تسمح لخادم إعادة التوجيه بالحصول على بيانات اعتماد `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 ssl` للمهاجم الموجود على المسار بانتحال صفة خادم مثبت على سلطة شهادات خاصة. يحدث هذا لأن `hackney ssl:merge ssl opts/3` يحتفظ باستدعاء افتراضي `{partial chain, fun hackney ssl:partial chain/1}` حتى عندما يستبدل المستخدم مخزن الثقة بـ `cacerts` أو `cacertfile` في `ssl options`. وبما أن OTP يمنح الأولوية لهذا الاستدعاء على مخزن الثقة المكون، يتم قبول أي سلسلة شهادات تنتهي بجذر موثوق به علنًا، مما يتجاوز تثبيت سلطة الشهادات الخاصة. يجب أن يمتلك المهاجم شهادة موثوقة علنًا لاسم المضيف المثبت لنجاح العملية.

توجد مشكلة في تخصيص الموارد في `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 جيجابايت.