Pdf.js: انتهاكات CSP للمضمون غير الآمن في [email protected]

تم إنشاؤها على ٢ أغسطس ٢٠١٩  ·  24تعليقات  ·  مصدر: mozilla/pdf.js

أرفق (موصى به) أو رابط إلى ملف PDF هنا:

إعدادات:

  • إصدار Chrome 76.0.3809.87 (الإصدار الرسمي) (64 بت)
  • نظام التشغيل Ubuntu 18.04.2 LTS (Bionic Beaver)
  • إصدار PDF.js: pdfjs-dist v2.2.228
  • امتداد المتصفح: لا

خطوات إعادة إظهار المشكلة:
لدينا سياسة أمان للمحتوى تمنع unsafe-inline .
انتهك هذا السطر السياسة في v2.2.228 Function ("r"، "regeneratorRuntime = r") (وقت التشغيل)؛

معلومات اضافية:
إصدار مماثل # 10229

1-other

التعليق الأكثر فائدة

أعتقد أنه يمكن إغلاق هذه المشكلة الآن ، لأن الإصدار القادم سيحتوي على نوعين من

  • بناء حديث (للمتصفحات الحديثة) ، لا يتم نقله باستخدام Babel وبدون أي polyfill مضمّن.
  • بناء متوافق مع ES5 (يمكن استخدامه على سبيل المثال مع IE11) ، والذي يتم نقله باستخدام Babel ويتضمن جميع polyfills الضرورية.

ال 24 كومينتر

انتهك هذا السطر السياسة في v2.2.228 Function ("r"، "regeneratorRuntime = r") (وقت التشغيل)؛

هذا ليس في الواقع رمز نشأ في أي مكان داخل مكتبة PDF.js نفسها ، ولكنه يأتي من Babel polyfill اللازم لدعم async / await في متصفح أقدم. على هذا النحو ، لسوء الحظ ، ليس من الواضح على الإطلاق ما الذي يمكن فعله (إن وجد) حيال ذلك هنا .

نعم ، أعتقد أنه يجب الإبلاغ عن هذا في المنبع بدلاً من ذلك.

يمكن كتابة timvandermeij Code في pdf.js بحيث لا تكون هناك حاجة إلى polyfill.
Snuffleupagus أي تلميحات في ملف whta للنظر فيه؟

نظرت أعمق في ذلك. لا توجد فرصة :-(

ها هي المشكلة regenerator-runtime / runtime.js .

نفس المشكلة هنا.

Snuffleupagus هل من الممكن توزيع ملفين منفصلين أحدهما للمتصفح الأقدم والثاني للمتصفحات دائمة الخضرة؟

هل هناك أي مشكلة في المنبع يجب تتبعها؟ تواجه نفس المشكلة حاليا

يمكنك الإبلاغ عن المشكلة إلى https://github.com/facebook/regenerator. يبدو أنهم قاموا بإصلاح بعض انتهاكات CSP هناك من قبل ، لذلك ربما يكونون على استعداد لإصلاح هذا أيضًا. إذا قاموا بإصلاحه في المنبع ، فيمكننا تحديث الإصدار الذي نستخدمه لإصلاحه من جانبنا أيضًا.

يبدو أن مؤلفي pdf.js قد أصلحوا هذه المشكلة هنا

https://github.com/facebook/regenerator/pull/353

لكن القضايا المستحقة على بابل كان عليهم التراجع عنها

https://github.com/facebook/regenerator/pull/369

يبدو أن لدينا مأزق هنا. أرى ثلاثة حلول هنا:

  • انتظر حتى يصلح facebook/regenerator المشكلات.
    قد يكون أوضح ولكن الكثير من المستخدمين سوف يلتزمون بإصدار قديم من pdf.js
  • الرجوع إلى إصدار سابق facebook/regenerator (ربما يجب أيضًا إرجاع Babel إلى إصدار سابق)
  • قدم بالإضافة إلى ES5 الحالي إصدارًا دائمًا (ES2016 +) من pdf.js لا يحتاج إلى facebook/regenerator . (الكثير من تطبيقات الويب الحالية لا تحتاج إلى أن تكون متوافقة مع ES5).

على أي حال فإن انتهاك CSP موثق جيدًا هنا
https://github.com/facebook/regenerator/blob/6e9e8d7747c2ab49927bdd9dd6261753181faec1/packages/regenerator-runtime/runtime.js#L716 -L725

  // This module should not be running in strict mode, so the above
  // assignment should always work unless something is misconfigured. Just
  // in case runtime.js accidentally runs in strict mode, we can escape
  // strict mode using a global Function call. This could conceivably fail
  // if a Content Security Policy forbids using Function, but in that case
  // the proper solution is to fix the accidental strict mode problem. If
  // you've misconfigured your bundler to force strict mode and applied a
  // CSP to forbid Function, and you're not willing to fix either of those
  // problems, please detail your unique predicament in a GitHub issue.
  Function("r", "regeneratorRuntime = r")(runtime);

هذا يعني أنه إذا كان لديك انتهاك لـ CSP ، فلا يجب عليك تشغيل هذا في الوضع المتشدد. نظرًا لأن هذا سلوك معروف في وقت تشغيل المُجدِّد ، يجب على ملف pdf.js إيقاف تشغيل الوضع المتشدد.

timvandermeij هل يمكنك إعادة قراءة التعليق من فضلك إذا كانت هناك مهمة يجب القيام بها لـ pdf.js أم لا؟

لا أرى حقًا ما يمكن أن يفعله PDF.js بشكل مختلف هنا. على الرغم من أن التعليق واضح ، فإننا نقوم عن قصد بتشغيل PDF.js بوضع صارم لمنع الأخطاء والسماح بالتحسينات. بالنظر إلى أن هذا لم يحدث من قبل ولا نستخدم حتى facebook/regenerator مباشرة (ولكن فقط كتبعية لحزمة أخرى) أود أن أقول أنه يجب تصحيح هذه ، ما لم يكن هناك تغيير تافه يمكننا / يجب أن أفعله من جانبنا ، لكنني لا أعرف ماذا سيكون ذلك بعد ذلك ...

تضمين التغريدة

شكرا لاكتشاف ذلك.

ماذا عن نسخة بابل المجانية من pdf.js؟ لا يجب أن يحتاج المتصفح الحديث إلى polyfill لوقت تشغيل المُجدد.

jkroepke من الناحية المثالية ، لن نستخدم Babel على الإطلاق ، ولكن للأسف من المطلوب الآن أن يعمل PDF.js في جميع المتصفحات التي ندعمها ، لذا فإن التخلص منها ليس شيئًا يمكننا التفكير فيه الآن. بالطبع يمكنك إنشاء PDF.js بنفسك وتعطيل نقل بابل.

أواجه نفس المشكلة مع 2.3.200. أي حل أو إصلاحات؟ شكرا.

تضمين التغريدة

في النهاية ، أرى أن ملف pdf.js يقوم بذلك بشكل خاطئ لأنه يستخدم الوضع المتشدد الذي لا يتم دعمه عند استخدام regenerator-runtime / babel. لذلك لم تعد مشكلة المنبع لأن القيود موثقة جيدًا.

أرى 4 بدائل لحل هذه المشكلات:

  • استخدام نسخة قديمة من بابل. الإصدار 2.1.266 من pdf.js لا يحتوي على هذه المشكلة. تثبيت الإصدارات يجب حلها. يجب أن يكون هذا هو الأسرع.
  • لا تستخدم الوضع المتشدد لأن تبعيات بابل لا تدعمه.
  • قم بإيقاف تشغيل ملحقات Transpile باستخدام وقت تشغيل المُجدد. (https://caniuse.com/#feat=es6-generators)
  • قم بتوفير نسختين من pdfjs-dist. واحد للمتصفحات القديمة (تم تحويله إلى ES5) والآخر للمتصفحات الحالية. (transpile إلى ES6)

استخدام نسخة قديمة من بابل. الإصدار 2.1.266 من pdf.js لا يحتوي على هذه المشكلة. تثبيت الإصدارات يجب حلها. يجب أن يكون هذا هو الأسرع.

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

[...] (https://caniuse.com/#feat=es6-generators)

فقط للتوضيح: يرجى ملاحظة أن مكتبة PDF.js لا تستخدم (حاليًا) أي وظائف منشئ ، ومع ذلك يتم استخدام async / await ولهذا السبب توجد هذه التبعية الخاصة هنا.

قم بتوفير نسختين من pdfjs-dist. واحد للمتصفحات القديمة (تم تحويله إلى ES5) والآخر للمتصفحات الحالية. (transpile إلى ES6)

يبدو أن هذا هو الخيار الأكثر واقعية من بين الاقتراحات أعلاه ، ولكن كيف / متى سيحدث ذلك ليس واضحًا في هذا الوقت (لاحظ المناقشة / المشكلات في PR # 11241).
ومع ذلك ، لاحظ أنه سيتم توفير الأنواع (العامة) التالية فقط من البنيات:

  • الإصدارات المتوافقة فقط مع أحدث إصدار من ES- {، أيًا كان ذلك في ذلك الوقت ، أي أن الملفات التي تم إنشاؤها لا يتم تشغيلها من خلال Babel ولا يتم تضمين polyfill.
  • البنايات المتوافقة مع ES5 ، أي يتم تحليل الملفات التي تم إنشاؤها بواسطة Babel مع تضمين polyfills.

إصدارات متوافقة فقط مع أحدث ES- {version}

هل تحترم استخدام الوظائف / التقنيات التي يدعمها أحدث إصدارين رئيسيين من المستعرضات فقط؟

لن يساعدنا الإصدار الذي يحتوي على وظائف مقترحات لغة فائقة التطور والتي لا يدعمها متصفح أحدث.

هل تحترم استخدام الوظائف / التقنيات التي يدعمها أحدث إصدارين رئيسيين من المستعرضات فقط؟

سيتطلب ذلك إنتاج ثلاثة أنواع مختلفة من البنيات ، والتي لا تبدو فكرة رائعة. على سبيل المثال ، من المحتمل أن يكون المستخدمون أكثر ارتباكًا فيما يتعلق بالبنية التي يجب استخدامها (لأنني أتخيل أن المستخدمين غير متأكدين حتى مع وجود نوعين فقط من البنيات). علاوة على ذلك ، فإن محاولة توفير العديد من البنيات ستضع مزيدًا من الضغط ، على سبيل المثال فيما يتعلق بكل من الدعم والصيانة ، على عدد قليل من المساهمين المنتظمين في PDF.js.

في الأساس ، فإن الموقف المرغوب في هذه الحالة بقدر ما أشعر بالقلق هو أن مستخدم المكتبة إما:

  • يختار أحدث إصدار من ES ، ويوفر polyfills حسب الضرورة بناءً على الأنظمة الأساسية / المتصفحات التي يحتاجون إلى دعمها.
  • يختار بناء ES5 ، ويحصل على جميع polyfill الضرورية المضمنة والتعليمات البرمجية المتوافقة مع "جميع" المتصفحات الحديثة.

لن يساعدنا الإصدار الذي يحتوي على وظائف مقترحات لغة فائقة التطور والتي لا يدعمها متصفح أحدث.

من الناحية التاريخية ، لا أعتقد أننا بدأنا في استخدام الوظائف على الفور عندما أصبحت متاحة في Firefox Nightly ، وبالتالي لا يمكنني توقع أن تكون هذه مشكلة كبيرة في الواقع.

أهلا،

واجهت نفس المشكلة ، وكان الحل الذي استخدمته هو تحميل وقت تشغيل المُجدد الذي اعتقدت فيه أن polyfill الخاص بي مباشرة.

بهذه الطريقة لم أغير pdfjs-dist. لقد سمح لي بحل مشكلات CSP الخاصة بي دون الحاجة إلى إعادة تجميع ملفات pdfjs :)

makidelille هل تستخدم الزاوي؟

makidelille هل تستخدم الزاوي؟

نستخدم angularjs ( لا يزال ).

على وجه الدقة ، قمنا ببناء عارض مخصص أعلى ملف pdf.js يتم استخدامه من خلال توجيه angularjs

تحرير: يتم إنشاء العارض المخصص باستخدام angularjs من النوع المطبوع ، ولهذا السبب لدينا polyfills.

أتلقى خطأ مضمّنًا آخر غير آمن لـ CSS ، من هذا السطر من التعليمات البرمجية:
https://github.com/mozilla/pdf.js/blob/master/web/ui_utils.js#L893

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src ...". Either the 'unsafe-inline' keyword, a hash ('sha256-MW4Iy/yu3WipUpTMM/T6OjvUu9R6vUwutodlmYNo6qM='), or a nonce ('nonce-...') is required to enable inline execution.

أهلا،

واجهت نفس المشكلة ، وكان الحل الذي استخدمته هو تحميل وقت تشغيل المُجدد الذي اعتقدت فيه أن polyfill الخاص بي مباشرة.

بهذه الطريقة لم أغير pdfjs-dist. لقد سمح لي بحل مشكلات CSP الخاصة بي دون الحاجة إلى إعادة تجميع ملفات pdfjs :)

هل تعرف (أو أي شخص آخر) كيف يمكن ترجمة هذا الحل إلى الزاوية 2+؟ هل من الممكن لإصلاح هذا؟

أنا أستخدم هذه المكتبة وأواجه نفس مشكلة CSP (إذا كنت ترغب في رؤية تذكرتي في قائمة مشكلات المشاريع هذه) ، ولكن هذه الأنواع من المشاكل مع الحزم / npm / عناصر نوع التبعية ليست شيئًا أفهم كل ذلك حسنا.

لسوء الحظ ، لا يبدو أن الإصدار القديم من pdfjs الذي لا يحتوي على هذه المشكلة (2.1.266 ، كما هو مذكور أعلاه) متوافق مع مكتبة المجمع الزاوي 2+ ، ولا يبدو أنه يحتوي على إصدار يستخدم هذا الإصدار من ملفات pdfj داخليا.

تحرير: بالنسبة لأي شخص في موقف مشابه مثلي ، هناك مكتبة مجمعة أخرى بتنسيق pdfjs الزاوية تعمل معي بدون مشكلات CSP. انظر هنا .

أعتقد أنه يمكن إغلاق هذه المشكلة الآن ، لأن الإصدار القادم سيحتوي على نوعين من

  • بناء حديث (للمتصفحات الحديثة) ، لا يتم نقله باستخدام Babel وبدون أي polyfill مضمّن.
  • بناء متوافق مع ES5 (يمكن استخدامه على سبيل المثال مع IE11) ، والذي يتم نقله باستخدام Babel ويتضمن جميع polyfills الضرورية.

يبدو جيدا! شكرًا Snuffleupagus وعمل الجميع على هذا: 1st_place_medal:

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات