IDOR + XSS المخزّن عبر كسر التفويض على مستوى الكائن في JoomGallery

JoomGallery ≤ 4.3.0 — مستخدم بدور المحرر يختطف أي صورة في المعرض ويخزّن حمولة XSS، مما يتيح الاستيلاء على جلسة المسؤول

الملخص

تتحقق الدالة UserimageController::save() في JoomGallery من checkACL('edit', ...) بدلاً من checkACL('edit.own', ...). يمكن لمستخدم بدور المحرر إرسال طلب POST إلى task=userimage.save&id=N لأي صورة بغض النظر عن مالكها (IDOR — CWE-639). ولأن دور المحرر يملك صلاحية core.edit بشكل عام، فإن فحص التفويض ينجح لكل معرّف صورة على الموقع، بما في ذلك الصور المملوكة للمسؤولين.

إلى جانب غياب استدعاء $this->escape() في قالب الصورة بواجهة المستخدم الأمامية، يمكن للمحرر تخزين حمولة XSS في عنوان أي صورة — بما في ذلك الصور المملوكة للمسؤول — مما يتسبب في تنفيذ JavaScript في متصفح كل زائر. وهذا يتيح اختطاف جلسة المسؤول بالكامل والاستيلاء على الموقع بأكمله.

الإصدارات المتأثرة

تفاصيل الثغرة

النوع: كسر التفويض على مستوى الكائن / IDOR (CWE-639) بالتزامن مع XSS المخزّن (CWE-79) المصادقة المطلوبة: حساب محرر بصلاحيات منخفضة

السبب الجذري 1 — IDOR (CWE-639)

الملف: components/com_joomgallery/src/Controller/UserimageController.php

ينفّذ إجراء save() فحص ACL باستخدام صلاحية edit بدلاً من edit.own. تُمنح صلاحية edit لجميع مستخدمي دور المحرر بشكل عام، لذا ينجح الفحص لأي معرّف صورة بغض النظر عمّن أنشأها.

USERIMAGECONTROLLER.PHP — الكود المعرّض للثغرة (السطر 145)

// Vulnerable
if (!$this->checkACL('edit', 'image', $recordId, $parent_id, true)) { ... }

ونظرًا لأن مجموعة المحررين تمتلك core.edit بشكل عام، فإن الشرط يُقيَّم على أنه false لكل معرّف صورة، مما يمنح صلاحية كتابة غير مقيدة. وعند نجاح الحفظ، يقوم النموذج (Model) أيضًا بتحديث created_by إلى معرّف المستخدم المهاجم، مما ينقل ملكية الصورة إلى المهاجم بصمت.

السبب الجذري 2 — XSS المخزّن (CWE-79)

الملف: components/com_joomgallery/tmpl/image/default.php

يقوم قالب الصورة الأمامي بطباعة $this->item->title دون ترميز HTML في سياق خاصية alt. لا يزيل فلتر STRING في JInput الخاص بجملة علامات الاقتباس المزدوجة، لذا فإن حمولة تحتوي على " تخرج من الخاصية وتحقن معالجات أحداث (Event Handlers) عشوائية.

DEFAULT.PHP — الكود المعرّض للثغرة (السطران 64 و78)

// Vulnerable
item->title; ?>" ...>

يتم تخزين الحمولة abc" onmouseover="alert(document.domain);" x=" في jos_joomgallery.title وحقنها كما هي في خاصية HTML عند كل عرض للصفحة. لا يحدث أي تنقية (Sanitization) في طبقة التخزين أو العرض.

إثبات المفهوم

نظرة عامة على سلسلة الهجوم

1. ينشئ المسؤول صورة في المعرض (ID=3). المالك = Administrator. الحالة منشورة ومعتمدة.
2. يسجّل المهاجم الدخول كمحرر. يستخرج ملف تعريف ارتباط الجلسة ورمز CSRF من صفحة تسجيل الدخول.
3. يجلب المهاجم رمز CSRF جديدًا من مكوّن JoomGallery.
4. IDOR: يرسل المحرر طلب POST إلى task=userimage.save&id=3 مع حمولة XSS في jform[title]. ينجح فحص ACL (core.edit وليس edit.own). يعيد الخادم HTTP 303 — وليس 403.
5. يتم تحديث العنوان بالحمولة غير المُهرَّبة. يتم تحويل created_by إلى معرّف المستخدم المهاجم.
6. يتم تخزين حمولة XSS دون تهريب في jos_joomgallery.title.
7. يتصفح أي زائر (أو مسؤول) الواجهة الأمامية للمعرض. يعرض القالب alt="abc" onmouseover="alert(document.domain);". تنطلق XSS. يتم التقاط جلسة المسؤول → استيلاء كامل على الموقع.

1. المسؤول ينشئ صورة في المعرض — المالك: Administrator، ID = 3

ينشئ المسؤول admin_image عبر واجهة إدارة JoomGallery الخلفية (Joomla 5.4.7). الصورة منشورة ومعتمدة ومملوكة بواسطة Administrator

2. المحرر يستخرج رمز CSRF من صفحة تسجيل الدخول

يحتوي استجابة JSON من GET /index.php/component/users/login على "csrf.token":"a68c2b3a...". يتم التقاط الرمز لطلب تسجيل الدخول POST اللاحق.

3. المحرر يسجّل الدخول — HTTP 303، joomla_user_state=logged_in

إرسال POST /index.php/component/users/login مع رمز CSRF وبيانات اعتماد المحرر. الاستجابة: HTTP 303 وSet-Cookie: joomla_user_state=logged_in. يتم التقاط ملف تعريف ارتباط الجلسة.

4. المحرر يستخرج رمز CSRF جديدًا من JoomGallery

إرسال GET /index.php?option=com_joomgallery مع ملف تعريف ارتباط الجلسة. تحتوي الاستجابة على "csrf.token":"2d96934b..." جديد لاستخدامه في طلب الحفظ.

5. حقن IDOR + XSS — الخادم يقبل مع HTTP 303

يرسل المحرر طلب POST إلى option=com_joomgallery&task=userimage.save&id=3 مع تعيين jform[title] إلى:

abc" onmouseover="alert(document.domain);" x="

يعيد الخادم HTTP 303 (وليس 403)، مما يؤكد وجود IDOR. يُظهر ترويسة Location حمولة XSS في رابط إعادة التوجيه، مما يؤكد قبول العنوان وحفظه.

6. نقل الملكية — تغيّر المالك إلى مستخدم المحرر

تعرض واجهة إدارة JoomGallery الخلفية أن الصورة ID=3 أصبح مالكها الآن: Editor User. تم تحديث حقل created_by بصمت في قاعدة البيانات أثناء الحفظ غير المصرح به.

7. قاعدة البيانات تؤكد تخزين الحمولة دون تهريب

يؤكد استعلام SQL على jos_joomgallery أن حمولة XSS مخزّنة — يتم تخزين " كعلامة اقتباس مزدوجة خام، وليس كـ ". لم يحدث أي تنقية في طبقة التخزين.

8. انطلاق XSS على الواجهة الأمامية للمعرض

أي مستخدم يزور /index.php/component/joomgallery/gallery يقوم بتشغيل الحمولة. يؤكد صندوق حوار alert() في المتصفح تنفيذ JavaScript في نطاق الضحية (document.domain).

الأثر

1. تعديل الصور غير المصرح به (IDOR): يمكن لمستخدم بدور المحرر تعديل أي صورة في المعرض على الموقع، بما في ذلك الصور المملوكة للمسؤولين، دون التحقق من الملكية.
2. نقل الملكية الصامت: كل عملية حفظ غير مصرح بها تعيد تعيين created_by للمهاجم بصمت، مما يغيّر مسار التدقيق بشكل دائم.
3. XSS المخزّن — تنفيذ مستمر: يتم تنفيذ حمولة JavaScript المحقونة في متصفح كل زائر عند كل تحميل لصفحة المعرض، مما يؤثر على الزوار غير المسجلين والمسؤولين على حد سواء.
4. اختطاف جلسة المسؤول → استيلاء كامل على الموقع: يمكن لبرنامج نصي خبيث في خاصية alt سرقة ملف تعريف ارتباط الجلسة الخاص بالمسؤول، مما يمنح المهاجم وصولاً كاملاً للواجهة الخلفية وتحكمًا في تثبيت Joomla بالكامل.
5. تغيير النطاق (Scope): يتم تنفيذ XSS في أصل متصفح الضحية (CVSS S:C)، متجاوزةً حدود الثقة بين جلسة المهاجم منخفضة الصلاحيات وجلسة الضحية عالية الصلاحيات.

المراجع

• CVE: https://www.cve.org/CVERecord?id=CVE-2026-66917
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-66917
• إعلان GitHub الأمني: https://github.com/advisories/GHSA-8vxv-gf52-gm5h
• مستودع المطوّر: https://github.com/JoomGalleryfriends/JoomGallery
• ملاحظة الإصدار الجديد من المطوّر: https://www.joomgalleryfriends.net/en/blog/joomgallery-4-en/joomgallery-4-4-0.html