Matte1782

يؤدي عدم التحقق من مطالبة الجمهور لرموز JWT (JSON Web Tokens) الخاصة بهوية مثيل GCE عند نقطة النهاية 'POST /api/v2/workspaceagents/google-instance-identity' إلى تمكين المهاجم من إعادة استخدام رمز هوية `format=full` غير منتهي الصلاحية تم إصداره لطرف ثالث معتمد. يمكن أن يؤدي ذلك إلى الحصول على رمز جلسة وكيل مساحة العمل بشكل غير مصرح به، والذي يظل صالحًا حتى عملية البناء التالية لمساحة العمل.

توجد مشكلة حيث يقوم النظام بالبحث عن عمليات التشغيل باستخدام `friendlyId` فقط في نقطة النهاية 'api.v1.runs.$runParam.replay' دون حصر البحث في بيئة تشغيل المستدعي. يتيح ذلك للمهاجم الذي يمتلك مفتاح API صالحًا لأي مستأجر ويعرف `friendlyId` الخاص بالضحية إعادة تشغيل تلك العملية في بيئته الخاصة وقراءة حمولة مهمة الضحية.

تفشل برامج الوسيطة BasicAuth و DigestAuth و ForwardAuth في Traefik في مراعاة أسماء الرؤوس التي تحتوي على متغيرات شرطة سفلية عند إزالة رؤوس الهوية المزيفة. في حين يتم إزالة الرؤوس ذات الحروف الكبيرة والصغيرة القياسية قبل أن يكتب Traefik قيمه الخاصة، قد يتم تجاهل المتغيرات التي تحتوي على شرطة سفلية. ونظرًا لأن العديد من الخلفيات تعمل على توحيد الرؤوس التي تحتوي على متغيرات شرطة سفلية بشكل مماثل للصيغ التي تحتوي على شرطة، يمكن للمهاجم حقن مثل هذه الرؤوس لتجاوز عملية الإزالة. وهذا يسمح بحقن هوية غير مصرح بها أو سياق تفويض يصل إلى الخلفية، ربما عبر مسار `authResponseHeaders` في ForwardAuth.

عند التشغيل في وضع HTTP مع تمكين `--lockdown-mode`، يتم تنفيذ `RepoAccessCache` كعنصر فريد شامل للعملية. يتم تهيئة هذا العنصر الفريد باستخدام عميل GraphQL الخاص بأول مستخدم تمت مصادقته، وتستمر الطلبات اللاحقة من مستخدمين مختلفين في استخدام نفس المثيل. ونتيجة لذلك، يتم تنفيذ استعلامات GraphQL المتعلقة بالحظر باستخدام بيانات اعتماد المستخدم الأول بدلاً من رمز الطلب الحالي. تؤثر هذه المشكلة على الدالة `GetInstance()` الموجودة في `pkg/lockdown/lockdown.go`، والتي تفشل في تحديث العميل الداخلي عند استدعائها من قبل مستخدمين مختلفين. ويؤدي ذلك إلى نتائج غير صحيحة في الدالة `IsSafeContent()`، التي تعتمد على `queryRepoAccessInfo` لتحديد ما إذا كان يجب الوثوق بالمحتوى الوارد من المساهمين الخارجيين أو تنقيته. تشمل الآثار المحتملة عمليات فحص غير صحيحة لرؤية المستودع، والوصول غير المصرح به إلى البيانات المخزنة مؤقتًا استنادًا إلى أذونات المستخدم الأول، وفشل تام لحماية الإغلاق في حالة انتهاء صلاحية رمز المستخدم الأول.

توجد مشكلة تتمثل في أن الدالة ` process picture url()` الموجودة في الملف `backend/open webui/utils/oauth.py` تقوم بالتحقق من صحة عنوان URL فقط على العنوان الأولي. وبالتالي، فإنها تستخدم `aiohttp.ClientSession.get()` دون تعيين `allow redirects=False` أو استخدام ثابت البيئة `AIOHTTP CLIENT ALLOW REDIRECTS`. ونظرًا لأن السلوك الافتراضي لـ aiohttp يسمح بما يصل إلى 10 عمليات إعادة توجيه، يمكن للمهاجم الذي يمتلك هوية صالحة من مزود هوية OAuth تقديم عنوان URL عام يعيد التوجيه إلى عنوان داخلي. وهذا يسمح للمهاجم بقراءة نص الاستجابة الداخلية من خلال حقل `profile image url` الخاص به، مما يؤدي إلى تزوير الطلبات من جانب الخادم (SSRF)، وهي حالة يتم فيها خداع الخادم لإجراء طلبات غير مقصودة إلى موارد داخلية أو خارجية.

توجد ثغرة في البرمجة النصية عبر المواقع (XSS) المخزنة في مسار المصادقة عبر OAuth. يستنتج النظام نوع MIME لعنوان URL الخاص بمطالبة الصورة من امتداد الملف بدلاً من رأس Content-Type، مما يسمح لملفات SVG بتجاوز أداة التحقق من صحة صورة الملف الشخصي وتخزينها كعناوين URI للبيانات. عندما يصل المستخدمون المصادق عليهم إلى نقطة نهاية صورة الملف الشخصي، يتلقون محتوى SVG يتحكم فيه المهاجم. ونظرًا لعدم وجود رؤوس أمان افتراضية واستخدام الترتيب المضمن (inline disposition)، يمكن تنفيذ البرامج النصية داخل نفس المنشأ، مما قد يؤدي إلى سرقة رموز المصادقة والاستيلاء على الحساب.

تحتوي نقطة نهاية واجهة برمجة التطبيقات (API) «subscriptions.create» الموجودة في «server/routes/api/subscriptions/subscriptions.ts» على نمط ترخيص معيب. عندما يتم توفير كل من `collectionId` و`documentId` في طلب ما، يقوم النظام بالتحقق من صحة التفويض لفرع المجموعة فقط. ومع ذلك، تقوم الدالة `subscriptionCreator()` الموجودة في ’server/commands/subscriptionCreator.ts‘ بإنشاء الاشتراك باستخدام `documentId`، الذي يظل غير مصدق عليه. ونظرًا لأن المخطط الموجود في ’server/routes/api/subscriptions/schema.ts‘ يسمح بإرسال كلا المعلمتين في وقت واحد، يمكن للمهاجم إنشاء اشتراك في مستند لا يمتلك حق الوصول للقراءة إليه في أي فريق ضمن المثيل.

يحتوي MCP Registry على ثغرة تتعلق بتزوير الطلبات من جانب الخادم (SSRF) في عملية التحقق من مساحة الأسماء القائمة على بروتوكول HTTP. يستخدم النظام دالة تسمى `safeDialContext` لمنع الاتصال بالعناوين الخاصة أو الداخلية عند استرداد ملفات المفاتيح العامة من النطاقات التي يوفرها الناشرون. ومع ذلك، فإن قائمة الحظر التي تستخدمها دالة `isBlockedIP()` لا تغطي العديد من مجموعات بادئات IPv6، بما في ذلك IPv6 6to4 (`2002::/16`)، وNAT64 (`64:ff9b::/96` و`64:ff9b:1::/48`) وعناوين الموقع المحلية (`fec0::/10`) التي تم إهمالها. يمكن لهذه البادئات ترميز عناوين IPv4 عشوائية، مما يسمح لها بالاتصال عبر نفق إلى خدمات RFC1918 الداخلية أو خدمات البيانات الوصفية السحابية على مضيفات ثنائية المكدس أو المضيفات التي تدعم NAT64. تؤثر هذه المشكلة على نقاط النهاية غير المصادق عليها ”/v0/auth/http“ و ”/v0.1/auth/http“. يمكن للمهاجم استغلال هذه الثغرة الأمنية عن طريق توفير نطاق ضار عبر المعلمة `domain` في نص الطلب. ونظرًا لأن الاتصال يحدث قبل التحقق من التوقيع، فلا توجد بيانات اعتماد مطلوبة لاستغلال هذه الثغرة. ويمكن أن يسمح ذلك لمهاجم غير مصدق بالوصول إلى الخدمات الداخلية، مثل خدمات البيانات الوصفية السحابية، أو خوادم واجهة برمجة تطبيقات Kubernetes، أو لوحات الإدارة الداخلية، واستخدام الخادم كأوراكل SSRF أعمى لاستكشاف الخدمات الداخلية.