Pdf.js: أدى التحسين الجزئي لنمط طبقة النص إلى طلب نمط- src "غير آمن - مضمّن" في سياسة أمان المحتوى

... أو ربما إعادة النظر في النهج.

كان PR # 7632 ضروريًا لتحسين أداء الوضع enhanceTextSelection وجه الخصوص ، والذي يعد جزءًا من المشكلة رقم 7584 ، لذلك في رأيي لا أعتقد أنه يجب حتى التفكير في العودة إلى هذا الوضع.

أنا أقترح فقط اتباع طرق أخرى لتحسينها. على سبيل المثال ، لماذا نستخدم 4 سمات حشو ثم نطبقها مع style بدلاً من دمجها؟

لا يزال من الممكن أيضًا استخدام أسلوب المصفوفة الثابتة لتعيين خصائص النمط الفردية بدلاً من القيام بكل ذلك عبر style . يمكن دمج الخصائص font-family و font-size مثل padding .

أنا أقترح فقط اتباع طرق أخرى لتحسينها. على سبيل المثال ، لماذا نستخدم 4 سمات حشو ثم نطبقها مع النمط بدلاً من دمجها؟

بشكل عام ، ليس هناك ما يضمن أن textDiv يحتاج إلى تحديث جميع قيم الحشو الأربع بـ enhanceTextSelection ، ويقدم الكود الحالي طريقة بسيطة للتعامل مع هذه الحالة (الشائعة جدًا).

لا يزال من الممكن أيضًا استخدام أسلوب المصفوفة الثابتة لتعيين خصائص النمط الفردية بدلاً من القيام بذلك كله عبر النمط.

كان السطر العام المنطقي وراء تحديث كل شيء مرة واحدة باستخدام style ، هو محاولة تجنب إبطال DOM دون داعٍ عند إنشاء / تحديث textDiv s حيث يبدو أن ذلك كان أحد المساهمين الرئيسيين في الأداء السيئ للوضع enhanceTextSelection .

بشكل عام ، ليس هناك ما يضمن أن textDiv معين يحتاج إلى جميع قيم الحشو الأربع المحدثة من خلال EnhanTextSelection ، ويقدم الكود الحالي طريقة بسيطة للتعامل مع هذه الحالة (الشائعة جدًا).

هذا لا يعني أنه لا يمكن استخدام padding بكفاءة. لا يحتاج إلى إنشاء سلاسل جديدة للأجزاء التي لا يتم تحديثها وستكون النتيجة النهائية أصغر. يمكن أن تحل محل سمة واحدة style مع مجموعة واحدة style.padding ويمكن إعادة استخدام "0".

كان السطر العام من المنطق وراء تحديث كل شيء مرة واحدة باستخدام النمط ، هو محاولة تجنب إبطال DOM دون داع عند إنشاء / تحديث textDivs حيث يبدو أن ذلك كان أحد المساهمين الرئيسيين في الأداء السيئ لوضع EnhanTextSelection.

ألا يحدث ذلك في جزء ، وليس في DOM الفعلي؟

هذا لا يعني أنه لا يمكن استخدام الحشو بكفاءة.

يوافق thestinger على أنه سيساعد على معالجة المشكلة إذا كانت المعايير مع بعض بيانات الأداء متاحة.

لست قادرًا حقًا على قياس الفرق بين الأساليب المختلفة هنا. يمكن تمييز الأساليب المختلفة خارج السياق بالرغم من ذلك.

أعتقد أنه يمكن تقليل التعارض مع unsafe-inline بدون خسارة في الأداء عن طريق تعديل هذا ومن ثم يمكن جعل التحسين مشروطًا إذا كان الاحتفاظ به مهمًا.

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

قد يكون هناك حل يسمح بالتحسين كما هو الحال أثناء دعم مواقع الويب باستخدام CSP.

هناك ثلاث طرق لتعيين النمط المضمَّن كسلسلة:

• element.setAttribute('style', someStyle) ، والذي لا يعمل عندما يكون هناك CSP لا يسمح بالمضمون غير الآمن
• element.style = someStyle ، وهو غير مدعوم في IE (تم اختباره على IE 11 ، لم أختبر هذا على Edge لذلك قد يتم كسره هناك أيضًا)
• element.style.cssText = someStyle ، وهو مدعوم اعتبارًا من المستوى 2 من DOM ، لذلك حتى IE يدعمه (تم التحقق منه على IE 11)

Plunker لإظهار الطرق الثلاث: https://plnkr.co/edit/T8xrUmR5eSuqDukSEVuw؟p=preview

سأكون أكثر من راغب في تقديم طلب سحب لتغيير element.setAttribute('style', ...) إلى element.style.cssText = ... إذا كنت توافق على هذا الحل.

يبدو أنه خطأ في المتصفح إذا كان element.style.cssText = someStyle يعمل بدون unsafe-eval :

• https://w3c.github.io/webappsec-csp/2/#directive -style-src
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/style-src#Unsafe_style_expressions

في حال واجه أي شخص آخر هذا ويريد حلاً ، فهذا هو التصحيح الحالي الذي أعيده إلى الطريقة القديمة للقيام بذلك ، لذلك يمكن تجنب style-src: 'unsafe-inline' :

https://github.com/GrapheneOS/pdf.js/commit/021d2fddb03883054ef4399d1d3df87e0c6ab9ca

يمكن بالتأكيد تحسينه قليلاً ، ولكن نظرًا لأن ذلك لا يهم بالنسبة لاستخدامي ، فأنا أبقي التصحيح عند أدنى حد ممكن لسهولة الصيانة. أعتقد أن توقع شخص ما يريد إصلاح مشكلة الأمان هذه ليهتم بتحسين الأداء أمر عكسي قليلاً. يجب أن يكون تحسين الأداء مقيدًا بما يمكن القيام به دون الإخلال بالنظافة الأمنية الأساسية. قد يكون من الأسرع التعامل مع هذا بطريقة مختلفة كما ذكرت أعلاه. تذكر رسالة الالتزام الخاصة بالتحسين مدى صعوبة قياس الاختلاف ، ولكن يمكن قياس الانحدار الأمني ​​بسهولة تامة.

السبب في أنني أستخدم pdf.js في المقام الأول هو الأمان. يسمح بإعادة استخدام عرض المتصفح المتصلب / المزود بوضع الحماية مع جميع عمليات العرض الخاصة بـ PDF في لغة آمنة للذاكرة (JavaScript). كجزء من القيام بذلك ، أستخدم CSP للتخفيف من إدخال الشفرة / النمط الديناميكي الذي يمكن أن يزيد بشكل كبير من سطح الهجوم ليصبح مثل صفحة الويب ، وهو أمر يتعارض تمامًا مع الأهداف. أعتقد أن العديد من الأشخاص الآخرين لديهم حالة استخدام مماثلة لـ pdf.js لتجنب مكتبات عرض PDF الأصلية الخطرة. يعد تجنب أنماط unsafe-inline جزءًا من التأكد من أن الخطأ لا يمكن أن يؤدي إلى حقن أنماط عشوائية عن طريق الخطأ ، مما يفتح الكثير من سطح هجوم العارض. بالنسبة لحالة الاستخدام حيث يتم تضمينها في موقع ويب فعلي ، فإن الأمر أكثر أهمية ، حيث يمكن القيام بالكثير من الأشياء الشريرة باستخدام CSS.

أعتبر هذا على نفس المستوى الذي نتوقع فيه أن يكون لدى الثنائيات / المكتبات الأصلية SSP و ASLR (PIE) و _FORTIFY_SOURCE=2 و -fstack-clash-protection وغيرها من عوامل التخفيف الأساسية. إنها النظافة الأمنية الأساسية مقابل الأشياء الأكثر تقدمًا مثل CFI على أساس النوع ، ومحاصرة المطهرات الصحيحة ، و ShadowCallStack ، وما إلى ذلك حيث أتوقع أن تفكر المشاريع الأكبر في الأمر وربما تعمل بالفعل عليها ولكنها ليست جزءًا من الحد الأدنى. إن سياسة CSP الأساسية مع JavaScript / CSS ثابتة مؤهلة لنظافة الأمان الأساسية في رأيي.

ثابت من خلال طلب السحب أعلاه.