Steffen Deusch

يحدث ثغرة Cross-site Scripting (XSS) عندما يتحكم المهاجم في أسماء السمات، مما يسمح بحقن سمات ونصوص برمجية في HTML المُصير عبر الدالة `Phoenix.HTML.attributes escape/1`. تفشل الدالة `key escape/1` في تحييد المسافات البيضاء في المفاتيح الثنائية بشكل صحيح، مما يسمح بإنشاء سمات جديدة مثل معالجات الأحداث. بالإضافة إلى ذلك، يتم تحويل مفاتيح atom إلى صيغة dasherized فقط، مما يسمح بمرور رموز مثل علامات الاقتباس والأقواس الزاوية. تؤثر هذه المشكلة على التطبيقات التي تبني مفاتيح السمات من مدخلات غير موثوقة وتقوم بتصييرها باستخدام HEEx `<tag {@attrs}>` أو `content tag/3` أو استدعاءات مباشرة. كما أن المفاتيح المتداخلة `data` و `aria` و `phx` عرضة للتأثر أيضاً. يمكن أن يؤدي ذلك إلى تنفيذ نصوص برمجية عشوائية في متصفحات المستخدمين الذين يشاهدون الصفحات المصابة.

توجد مشكلة إعادة توجيه مفتوحة (Open Redirect) حيث يمكن للمهاجم إعادة توجيه متصفح الضحية إلى مصدر عشوائي. يحدث هذا لأن الدالة `redirect/2` تستخدم `validate local url!/2` للتأكد من أن الهدف هو مسار محلي، لكنها تفشل في رفض أحرف ASCII tab أو LF أو CR. ونظرًا لأن المتصفحات تقوم بإزالة هذه الأحرف قبل تحليل عنوان URL، فإن قيمة مثل `/<TAB>/example.com` تتجاوز عملية التحقق من الصحة ويتم تفسيرها على أنها عنوان URL نسبي للمخطط. تتأثر الدالة `push patch/2` أيضًا في الإصدارات السابقة للإصدار 0.7.0. تظهر المشكلة عندما يمرر التطبيق قيمة متأثرة من مصدر خارجي كمعلمة `:to`، مثل معلمة `return to` أثناء تسجيل الدخول أو هدف التنقل من حمولة `handle event/3`.

توجد مشكلة في البرمجة النصية عبر المواقع في phoenix live view بسبب التحقق غير الصحيح من صحة مخطط عناوين URL. تستخدم الدالتان `valid destination!/2` و`valid live navigation destination!/2` أداة مساعدة داخلية `uri scheme/1` تفشل في اكتشاف المخططات إذا كانت المدخلات تبدأ بمسافة أو بحرف تحكم ASCII. ونظرًا لأن المتصفحات القياسية تزيل هذه الأحرف الافتتاحية قبل التحليل، يمكن للمهاجم تقديم حمولة مثل ” javascript:alert(1)“ التي تتجاوز عملية التحقق من الصحة ويتم التعامل معها على أنها مسار نسبي آمن. وعند عرضها عبر `<.link href={...}>`، يقوم المتصفح بتنفيذ البرنامج النصي في جلسة عمل الضحية. ويؤثر هذا على التطبيقات التي تعرض عناوين URL التي يقدمها المستخدم، مثل أهداف إعادة التوجيه أو روابط الملفات الشخصية.

يمكن لمهاجم غير مصدق أن يتسبب في هجوم رفض الخدمة ضد أي نقطة نهاية تقوم بتركيب مقبس Phoenix باستخدام وسيلة نقل قناة يمكن الوصول إليها، مثل WebSocket أو LongPoll. تكمن المشكلة في الروتين `Elixir.Phoenix.Socket`:handle in/4 الموجود في الملف lib/phoenix/socket.ex. نظرًا لأن وسائل النقل في Phoenix لا تحدد عدد القنوات التي يمكن لعملية نقل واحدة الانضمام إليها، يمكن للعميل إرسال عدد غير محدود من رسائل phx join عبر اتصال واحد. يؤدي هذا إلى إنشاء عمليات قنوات مفرطة، مما قد يستنفد الحد الأقصى لعدد العمليات في BEAM ويمنع الآلة الافتراضية من بدء عمليات جديدة لحركة المرور المشروعة. يحدث هذا التضخيم ضمن اتصال واحد، مما يجعل حدود الاتصال على مستوى طبقة الشبكة والحد من المعدل غير فعالين.

يحتوي عميل Presence JavaScript في phoenix على فحص غير سليم للحالات غير العادية، مما يسمح لمهاجم يتمتع بوصول عادي إلى القناة بالتسبب في رفض خدمة مستمر من جانب العميل لجميع مشاهدي موضوع قناة التواجد. تكمن المشكلة في ملف `assets/js/phoenix/presence.js` داخل روتينات `Presence.syncState()` و`Presence.syncDiff()`. يستخدم العميل اختبار «الصحة» البسيط (`state[key]`) بدلاً من فحص وجود خاصية خاصة للتحقق من وجود حالة التواجد. ونظرًا لأن مفاتيح التواجد تخضع لسيطرة المهاجم، يمكن للمستخدم تقديم مفتاح يطابق اسم عنصر في `Object.prototype` (مثل ` proto ` أو `constructor` أو `toString` أو `hasOwnProperty`). يؤدي هذا إلى إرجاع البحث `Object.prototype` المدمج بدلاً من `undefined`، مما يدفع الكود إلى محاولة قراءة `.metas.map(...)` من النموذج الأولي، الأمر الذي يطلق استثناء `TypeError` لم يتم التقاطه. يمنع هذا الاستثناء تحديث الحالة المحلية ويوقف تشغيل `onSync()`. ونظرًا لأن الخادم يستمر في دفع المفتاح الخبيث، تظل المزامنة معطلة لجميع مشاهدي الموضوع حتى يغادر المهاجم. وهذا يمثل خلطًا في وقت القراءة لكائن النموذج الأولي وليس تلوثًا للنموذج الأولي.