تسرب كلمة مرور البروكسي عبر عميل HTTP: ثغرة CVE في curl وlibsoup وrequests

عادةً ما يتم الحفاظ على كلمة مرور البروكسي بعيدًا عن الناس: لا يتم عرضها في لقطات الشاشة، ولا يتم إدراجها في git، ويتم الاحتفاظ بها في متغيرات البيئة. ولكن في عام 2026، تبين أن عميل HTTP نفسه يمكنه تسليمها. بين أبريل ويوليو، ظهرت عدة ثغرات في curl وlibcurl وlibsoup، حيث يتم إرسال رأس Proxy-Authorization إلى بروكسي غير صحيح، أو حتى مباشرة إلى الموقع المستهدف. أدناه تحليل للظروف التي يحدث فيها ذلك، وفحص خطوة بخطوة لستاك الخاص بك.

ماذا حدث: أربع تسريبات في أربعة أشهر

جميع هذه الأخطاء مصممة بنفس الطريقة: يحتفظ العميل باسم المستخدم وكلمة المرور لبروكسي واحد ويرسلها عن طريق الخطأ إلى الأمام عبر السلسلة.

• CVE-2026-6253 (curl وlibcurl 7.14.1–8.19.0). إذا كانت هناك بروكسيات مختلفة مهيأة لـ http:// وhttps://، حيث يتطلب الأول كلمة مرور، بينما لا يتطلب الثاني، فعند إعادة التوجيه عند تغيير البروتوكول، سيرسل curl بيانات اعتماد البروكسي الأول إلى الثاني. تُرسل البيانات بتشفير base64، مما يعني أنها في الواقع نص عادي. تم إصلاحها في curl 8.20.0، الذي صدر في 29 أبريل 2026. المتأثر هو curl من سطر الأوامر، وليس المكتبة فقط.
• CVE-2026-8927 (libcurl 7.12.0–8.20.0). تعيد التطبيق استخدام مقبض واحد لعدة طلبات، ويتم أخذ البروكسيات من متغيرات البيئة، بينما تتم المصادقة عبر Digest. في هذه الحالة، يتم إرسال رأس Proxy-Authorization لبروكسي A إلى بروكسي B، ويمكن لهذا الأخير تكراره ليظهر كأنه أنت. تم إصلاحها في curl 8.21.0 في 24 يونيو 2026. لم يتأثر curl من سطر الأوامر. تم وصف خطأ مشابه تقريبًا في CVE-2026-7168، والاختلاف الوحيد هو كيفية اختيار البروكسي.
• CVE-2026-12547 (libsoup، SoupAuthManager). يقوم libsoup بتخزين بيانات اعتماد البروكسي في الذاكرة المؤقتة دون ربطها بعنوان host:port. عندما تتغير إعدادات البروكسي (الإعدادات النظامية، WPAD)، يتم إرسال الرأس القديم إلى بروكسي جديد. تم نشره في 21 يوليو 2026، وتقييمه منخفض.
• CVE-2026-66339 (libsoup، أنفاق CONNECT). بعد إنشاء نفق CONNECT عبر بروكسي HTTP، يقوم libsoup بإرفاق Proxy-Authorization بالطلبات HTTPS التالية داخل النفق. يرى الرأس بالفعل الخادم المستهدف. CVSS 6.5، تم نشره في 24 يوليو 2026.

القصة ليست جديدة. في مكتبة Python requests من الإصدار 2.3.0 إلى 2.31.0 (CVE-2023-32681)، كان رأس Proxy-Authorization عند إعادة التوجيه إلى HTTPS يُرسل إلى الخادم المستهدف، إذا كانت بيانات الاعتماد مكتوبة مباشرة في عنوان بروكسي. في urllib3 حتى 1.26.19 و2.2.2 (CVE-2024-37891)، لم يتم حذف الرأس المعين يدويًا، وليس من خلال الدعم المدمج للبروكسي، عند إعادة التوجيه إلى مجال خارجي.

لماذا هذا مهم بشكل خاص للعمل مع البروكسيات

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

تبدو السيناريوهات الأكثر عرضة للخطر كما يلي:

• المكتشفات والمراقبات، التي تتبع إعادة التوجيه تلقائيًا. قد يؤدي الموقع المستهدف أو إعادة التوجيه الوسيطة إلى تحويل الطلب إلى مجال يجمع الرؤوس.
• السكريبتات مع عدة بروكسيات: بروكسيات مختلفة لمخططات مختلفة، تبديل البروكسيات بين الطلبات على اتصال واحد، خلط "بروكسي بكلمة مرور" و"بروكسي بدون كلمة مرور".
• العمليات طويلة الأمد على خوادم Linux، حيث تأتي libcurl وlibsoup مع الحزم النظامية ويتم تحديثها مع التوزيعة، وليس مع الكود الخاص بك.
• الشبكات المؤسسية مع WPAD وملفات PAC: يتغير البروكسي دون مشاركة التطبيق، وهذه الحالة هي ما تم وصفه في CVE-2026-12547.

كيفية فحص ستاك الخاص بك: خطوة بخطوة

1. اكتشف الإصدار الحقيقي من libcurl، وليس فقط curl من سطر الأوامر. تظهر الأمر curl -V كلاهما، لكن التطبيق قد يكون مبنيًا مع نسخته الخاصة من المكتبة. بالنسبة لـ Python مع pycurl، نفذ python -c "import pycurl; print(pycurl.version)"، بالنسبة لـ PHP استدعِ curl_version(). الحدود الآمنة: 8.21.0 وما بعدها أو الفروع المصححة 8.20.1+، 8.16.1+ و8.14.2+.
2. تحقق من التبعيات في Python. نفذ pip show requests urllib3. تحتاج إلى requests لا تقل عن 2.31.0 وurllib3 لا تقل عن 1.26.19 (فرع 1.x) أو 2.2.2 (فرع 2.x). إذا كانت التبعية تأتي بشكل غير مباشر، تحقق من pip list داخل نفس البيئة التي يعمل فيها المكتشف.
3. تحقق من libsoup على Linux. يتعلق هذا بتطبيقات GNOME وWebKitGTK وكل ما تم بناؤه على هذا الستاك. قم بتحديث الحزمة عبر مدير التوزيعة وتحقق من نشرة الأمان الخاصة بتوزيعتك: في بطاقات هذه CVE، تم الإشارة إلى RHEL 6–10 كمتأثرة من قبل Red Hat.
4. ابحث في الكود عن تعيين الرأس يدويًا. ابحث عن Proxy-Authorization في جميع المستودع. إذا تم تعيين الرأس يدويًا، وليس من خلال آلية البروكسي القياسية للعميل (proxies= في requests، ProxyManager في urllib3، CURLOPT_PROXYUSERPWD في libcurl)، فهذا مرشح للتسرب عند إعادة التوجيه.
5. ابحث عن إعادة استخدام الاتصالات عند تغيير البروكسي. مقبض واحد من libcurl، جلسة واحدة من requests أو وكيل HTTP واحد، يتم من خلالها إرسال الطلبات بالتتابع مع بروكسيات مختلفة. أبسط خيار للإصلاح: جلسة منفصلة لكل بروكسي.
6. قم بإيقاف إعادة التوجيه التلقائية حيثما لا تكون ضرورية. في requests، يكون ذلك allow_redirects=False، في urllib3 redirect=False، في curl لا تضع -L وCURLOPT_FOLLOWLOCATION. عندها يتم معالجة 3xx يدويًا، وتقرر بنفسك إلى أين تذهب بعد ذلك. هذه هي الطريقة التي يقدمها مؤلفو requests وurllib3.
7. قم بإجراء اختبار حي على الفخ. قم بإعداد خادم HTTP بسيط لديك، يطبع جميع الرؤوس الواردة، وقم بإجراء إعادة توجيه إلى خادم ثانٍ مماثل. اجري عبر المكتشف الخاص بك مع البروكسي سيناريو حقيقي، بما في ذلك تغيير البروتوكول من http إلى https. إذا رأى أي من الخوادم رأس Proxy-Authorization، فإن التسرب مؤكد في كودك، وليس في النظرية.

المزالق

• تعيش صور Docker حياتها الخاصة. قمت بتحديث curl على المضيف، بينما يعمل المكتشف في حاوية مع صورة أساسية قديمة. يجب التحقق داخل الحاوية: docker exec <الحاوية> curl -V.
• تحدث تحديثات curl من سطر الأوامر وlibcurl بشكل مختلف. لا تؤثر CVE-2026-8927 على curl من سطر الأوامر، بينما تؤثر CVE-2026-6253 عليه. لا تخبرك curl -V في الطرفية شيئًا عن المكتبة التي تم بناء PHP أو Python الخاص بك معها.
• Digest لا ينقذ. نعم، عند استخدام Digest، لا تذهب كلمة المرور كنص عادي. لكن في CVE-2026-8927، لا يحتاج المهاجم إلى كلمة المرور: يتم تكرار الرأس الذي تم التقاطه طالما أن nonce ساري.
• كلمة المرور في URL مريحة، لكنها خطيرة. ظهر التسرب في requests تحديدًا عندما كانت بيانات الاعتماد مكتوبة في عنوان بروكسي على شكل user:pass@host:port. هذا ليس سببًا للتخلي عن التنسيق، ولكن سببًا للحفاظ على المكتبات محدثة.
• قد تأتي إعادة التوجيه من مصدر غير مستهدف. صفحات CAPTCHA، لافتات الموافقة، مختصرات الروابط وCDN أيضًا تستجيب بـ 3xx. كلما زادت "التبعية للروابط" في الزاحف، زادت سطح الهجوم.

كيفية تقليل الأضرار إذا تسربت كلمة المرور

لا يمكن استبعاد التسرب تمامًا: غدًا ستظهر CVE التالية. لذلك من المهم معرفة تكلفة تسرب واحد.

• مشروع واحد، وصول واحد. لا تحتفظ باسم مستخدم مشترك لجميع المكتشفات. في ProxyCove، يحصل كل بروكسي يتم شراؤه على زوج منفصل من اسم المستخدم وكلمة المرور، لذلك فإن الوصول المسرب من سكريبت واحد لا يفتح حركة المرور لبقية السكريبتات.
• لا تحتفظ على وصول واحد بأكثر من حركة المرور اللازمة. قم بتعبئة القليل حسب الحاجة، وليس لستة أشهر مقدماً.
• راقب الاستهلاك. الزيادة المفاجئة في حركة المرور دون زيادة عدد المهام هي أول علامة على أن شخصًا آخر يستخدم وصولك.
• قم بتغيير كلمة المرور فورًا عند الشك وحسب الجدول. كيف يمكن تنظيم ذلك دون توقف، تم شرحه في دليل حول تدوير كلمات مرور البروكسي.

ما هو نوع البروكسي الذي يجب اختياره وما علاقته بذلك

لا يعتمد التسرب على نوع البروكسي: الخطأ موجود في العميل. لكن تكلفة التسرب تعتمد. بروكسيات مركز البيانات أرخص لكل جيجابايت، ومن المنطقي الاحتفاظ بها بشكل منفصل عن حركة المرور المكلفة عند الزحف إلى مواقع بسيطة مع إعادة توجيه متكررة. يجب تخصيص بروكسيات سكنية للمهام التي تحتاج إليها بالفعل، وإنشاء وصولات منفصلة لها مع إيقاف إعادة التوجيه التلقائية. من المنطقي الاحتفاظ بالبروكسيات المحمولة، الأكثر تكلفة لكل جيجابايت، في الكود مع الحد الأدنى من الاعتماد على جهات خارجية، وبالتأكيد مع التحقق من إصدارات المكتبات مع كل بناء.

الاستنتاج

يمكن أن تتسرب كلمة مرور البروكسي دون اختراق، دون فيروس، ودون خطأ بشري: يكفي أن يكون libcurl قديمًا، إعادة توجيه إلى مجال خارجي، وإعادة استخدام اتصال. قائمة التحقق قصيرة: curl وlibcurl من 8.21.0، requests من 2.31.0، urllib3 من 1.26.19 أو 2.2.2، libsoup محدث، جلسة منفصلة لكل بروكسي، إعادة التوجيه تحت السيطرة، واختبار حي واحد على الفخ. بالإضافة إلى وصول منفصل لكل مشروع، بحيث تكلف تسرب واحدة سكريبت واحد، وليس كل الرصيد.