Shirabe0X05

عندما يقوم الوكيل (Agent) بتركيب معترضات إعادة التوجيه والتخزين المؤقت المشترك، يمكن التحقق من صحة استجابة مخزنة مؤقتًا يتم إعادة التحقق منها باستخدام طلب شرطي بشكل خاطئ من خلال استجابة 304 Not Modified من مصدر مختلف. يحدث هذا لأن معالج إعادة التوجيه يقوم بإزالة ترويسات الاعتماد المرتبطة بالمصدر ولكن يفشل في إزالة أدوات التحقق `If-None-Match` أو `If-Modified-Since` التي أنشأها التخزين المؤقت. نتيجة لذلك، يتلقى وجهة إعادة التوجيه أداة التحقق الخاصة بالمصدر الأصلي، ويعتبر النظام استجابة 304 بمثابة إعادة تحقق ناجحة. قد يؤدي ذلك إلى قيام التخزين المؤقت المشترك بتقديم استجابة مصادق عليها، مثل تلك المحمية بترويسة `Authorization` ، إلى مستخدم غير مصادق عليه.

يفشل اعتراض إعادة التوجيه في إزالة الرؤوس الحساسة—بما في ذلك `Authorization` و `Cookie` و `Proxy-Authorization` و `Host`—عندما يتم إعادة توجيه الطلب إلى أصل مختلف إذا تم تقديم رؤوس الطلب كمصفوفة من توابل الاسم والقيمة. في هذا السيناريو، يسيء معالج إعادة التوجيه تفسير التوابل على أنها قائمة مسطحة، مما يمنع تطابق أسماء الرؤوس ويسمح ببقاء الرؤوس الحساسة. إذا تم تركيب معترض لتطبيع الرؤوس، مثل cache أو deduplicate، خارج معترض إعادة التوجيه، يتم حينئذٍ تسلسل هذه الرؤوس المحتفظ بها في طلب الأصل المتقاطع، مما قد يؤدي إلى كشف بيانات اعتماد الأصل لجهة وجهة إعادة توجيه غير ذات صلة.

يوجد خلل في التصريح في مهمة `login.invite`. يسمح هذا الخلل لمؤلفي الصفحات بالحصول على حسابات مستخدمين خارقين (super user) من خلال تحديد نموذج دعوة يمنح وصولاً خارقاً في frontmatter الصفحة. يمكن للمهاجم غير المصرح له إرسال هذا النموذج وتسجيل العنوان المدعو للسيطرة الكاملة على الموقع.

يوجد تجاوز للصلاحيات في نقطة نهاية واجهة برمجة التطبيقات (API) العامة '/api/v1/flex-objects/pages'. تحدث هذه المشكلة لأن النظام يتحقق فقط من صلاحيات `admin.pages` على مستوى الدليل، دون فرض قواعد الصلاحيات على مستوى الصفحة أو صلاحيات `api.pages.read/write` الخاصة بواجهة برمجة تطبيقات الصفحات. نتيجة لذلك، يمكن للمستخدمين الموثقين غير الخارقين الذين لديهم صلاحيات `api.access` و `admin.pages` أو `admin.configuration.pages` قراءة مصدر الصفحة والبيانات الوصفية (frontmatter)، أو تعديل المحتوى، أو حذف الصفحات التي لا يملكون تصريحاً للوصول إليها.

توجد مشكلة في التحكم في الوصول في الدالة `dynamicFlexField()` ضمن `FlexDirectory`. يسمح هذا لمؤلفي الصفحات باستدعاء طرق كائنات Flex تعسفية عبر توجيهات `flex-*@` في frontmatter الصفحة. عندما يقوم مستخدم لديه صلاحيات تحرير الصفحة بفتح الصفحة المتأثرة، يتم تنفيذ التوجيهات التي تستدعي `setStorageKey()` و `delete()` ضمن جلسته، مما قد يؤدي إلى حذف صفحات محمية لا يملك أي من الحسابين صلاحية حذفها.