Cedric Bonhomme

توجد مشكلة في البرمجة النصية عبر المواقع (XSS) المخزنة في مرشح Jinja `render tag badges` المستخدم لعرض علامات المراجع لسجلات الثغرات الأمنية. يقوم التطبيق بإدراج القيم مباشرةً من `containers.cna.references[].tags[]` في عناصر شارات HTML ويغلف النتيجة في `markupsafe.Markup`، مما يتجاوز عملية الترميز التلقائي لـ HTML في Jinja. يمكن للمستخدم المصادق عليه الذي يمتلك أذونات `vulnerability:create` أو `vulnerability:modify` إرسال علامات مرجعية مصممة خصيصًا عبر واجهة برمجة تطبيقات CNA تحتوي على HTML أو JavaScript تعسفي. يتم تخزين هذا المحتوى الضار وتنفيذه لاحقًا في متصفح أي مستخدم يزور نقاط النهاية العامة `/cve/<id>` أو `/vuln/<id>`. وقد يتيح ذلك للمهاجم تنفيذ إجراءات نيابة عن الضحية، أو الوصول إلى معلومات الجلسة، أو تعديل محتوى الصفحة، مما قد يؤثر على المستخدمين غير المصادق عليهم.

يوجد ثغرة في تجاوز التفويض بسبب عدم الاتساق في التطبيق بين واجهة برمجة التطبيقات REST وواجهة البث Server-Sent Events (SSE). تستخدم واجهة Pub/Sub زخرفة `token required` التي تقوم بمصادقة الطلبات من خلال مطابقة رأس `X-API-KEY` مع مفتاح API الخاص بالمستخدم، لكنها تفشل في التحقق مما إذا كان الحساب نشطًا أو مؤكدًا. ونظرًا لأن مفاتيح واجهة برمجة التطبيقات (API) تُصدر أثناء التسجيل الذاتي قبل اكتمال عملية التأكيد، يمكن للمستخدمين غير المصرح لهم الوصول إلى نقطة النهاية `/pubsub/subscribe/<topic>`. وهذا يسمح بالوصول إلى أحداث البث، مثل التعليقات غير الخاضعة للإشراف، والتي تكون مقيدة بخلاف ذلك عبر واجهة برمجة التطبيقات (REST API).

توجد ثغرة في آلية تفعيل الحساب واستعادة كلمة المرور. يستخدم النظام رموزًا موقعة عديمة الحالة لا تحتوي سوى على اسم تسجيل دخول المستخدم. ورغم التحقق من صحة التوقيع ومدة صلاحية الرمز، إلا أن التطبيق لا يتتبع ما إذا كان الرمز قد استُخدم من قبل أم لا. ونتيجة لذلك، يظل رابط التنشيط أو الاسترداد الذي تم التقاطه صالحًا طوال مدة `TOKEN VALIDITY PERIOD`، حتى بعد تغيير كلمة المرور. وهذا يسمح للمهاجم الذي يمتلك رمزًا صالحًا بإعادة استخدامه عدة مرات لإعادة تعيين كلمة المرور والسيطرة على الحساب. علاوة على ذلك، فإن الرموز غير مقيدة بغرض محدد، مما يتيح استخدام الرمز نفسه في كل من عمليات التنشيط والاسترداد. يتطلب استغلال هذه الثغرة الحصول على رابط صالح، ولكنه لا يتطلب كلمة مرور الضحية الحالية أو جلسة عمل نشطة.

توجد مشكلة تزوير الطلبات من جانب الخادم (SSRF) في وظيفة مزامنة المثيلات البعيدة. كان النظام يتحقق من صحة عناوين المثيلات البعيدة فقط من حيث صيغة URL الأساسية قبل التخزين، بينما كان عامل المزامنة يعالج هذه العناوين لاحقًا باستخدام `requests.get()` مع معالجة إعادة التوجيه التلقائية وبدون قيود على حدود الشبكة. يمكن للمسؤول المصادق عليه الذي يمتلك إذن `admin:access` تكوين مثيل بعيد يشير إلى خدمات HTTP(S) داخلية أو خدمات loopback أو خدمات link-local أو خدمات بيانات تعريفية سحابية. بالإضافة إلى ذلك، يمكن استخدام عنوان URL متاح للجمهور لإعادة التوجيه إلى وجهة داخلية نظرًا لأن عمليات إعادة التوجيه كانت تُتبع دون إعادة التحقق. وهذا يسمح لمهاجم يتمتع بامتيازات بالتحري عن الخدمات التي يمكن الوصول إليها من سياق شبكة الخادم أو التفاعل معها، مثل خدمات الشبكة الخاصة أو نقاط نهاية بيانات تعريفية للمثيلات السحابية.

يستخدم أداة التحقق من صحة عناوين URL الخاصة بـ webhook في الملف `website/notifications/webhooks.py` الدالة `ip.is global` لرفض العناوين غير العامة بعد تحليل DNS. ومع ذلك، فإن عناوين IPv6 الانتقالية، مثل NAT64 `64:ff9b::/96`، و6to4 `2002::/16`، وTeredo `2001:0000::/32`، تُصنف من قبل IANA على أنها قابلة للتوجيه عالميًا. ونتيجة لذلك، تُرجع دالة `is global` القيمة `True` حتى لو كان عنوان IPv4 المضمن يستهدف وجهة خاصة أو وجهة loopback أو وجهة بيانات وصفية سحابية. وهذا يسمح للمهاجم بتسجيل ويبهوك يشير إلى اسم مضيف يتم تحليله إلى عنوان انتقالي، متجاوزًا الحماية من تزوير الطلبات من جانب الخادم (SSRF) لتسريب البيانات إلى نقطة نهاية داخلية.