Pdf.js: Violaciones de CSP por inseguridad en línea en [email protected]

La política es violada por esta línea en v2.2.228 Function ("r", "regeneratorRuntime = r") (tiempo de ejecución);

En realidad, ese código no se origina en ningún lugar dentro de la biblioteca PDF.js, sino que proviene de un polyfill de Babel necesario para admitir async / await en un navegador anterior. Como tal, desafortunadamente no está del todo claro qué (si es que se puede hacer algo) al respecto aquí .

Sí, creo que esto debería informarse en su lugar.

@timvandermeij El código en pdf.js podría escribirse para que no sea necesario el polyfill.
@Snuffleupagus ¿ Alguna

Lo examiné más profundamente. Ninguna posibilidad :-(

Aquí está el problema regenerator-runtime / runtime.js .

El mismo problema aquí.

@Snuffleupagus , ¿es posible distribuir 2 archivos separados, uno para el navegador más antiguo y el segundo para los navegadores de hoja perenne?

¿Hay algún problema aguas arriba para realizar un seguimiento? Enfrentando el mismo problema actualmente

Puede informar el problema a https://github.com/facebook/regenerator. Parece que arreglaron algunas violaciones de CSP allí antes, por lo que tal vez estén dispuestos a arreglar esto también. Si lo arreglan en sentido ascendente, también podemos actualizar la versión que usamos para arreglarlo de nuestro lado.

Parece que los autores de pdf.js solucionaron este problema aquí

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

pero debido a problemas en babel, tuvieron que revertirlo

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

Parece que tenemos un punto muerto aquí. Veo tres soluciones aquí:

• Espere hasta que facebook/regenerator solucione los problemas.
  Puede que sea el más claro, pero muchos usuarios se apegarán a una versión antigua de pdf.js
• Babel facebook/regenerator (tal vez babel también deba ser degradado)
• Proporcione además del ES5 actual una versión perenne (ES2016 +) de pdf.js que no necesita facebook/regenerator . (Muchas de las aplicaciones web actuales no necesitaban ser compatibles con ES5).

De todos modos, la violación de CSP está bien documentada aquí.
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);

Significa que, si tiene una infracción de CSP, no debe ejecutarla en modo estricto. Dado que este es un comportamiento conocido en regenerator-runtime, pdf.js debe desactivar el modo estricto.

@timvandermeij ¿Puedes releer el comentario por favor si hay una tarea pendiente para pdf.js o no?

Realmente no veo qué podría hacer PDF.js de manera diferente aquí. Aunque el comentario es claro, intencionalmente ejecutamos PDF.js con modo estricto para evitar errores y permitir optimizaciones. Dado que esto no sucedió antes y ni siquiera usamos facebook/regenerator directamente (pero solo como una dependencia de otro paquete), diría que deberían ser parcheados, a menos que haya un cambio trivial que podamos / tenemos que hacer de nuestro lado, pero no sé qué sería entonces ...

@timvandermeij

Gracias por resolverlo.

¿Qué tal una versión gratuita de babel de pdf.js? Los navegadores modernos no deberían necesitar polyfill en tiempo de ejecución de regenerador.

@jkroepke Idealmente, no

Estoy experimentando el mismo problema con 2.3.200. ¿Alguna solución o arreglos? Gracias.

@timvandermeij

Al final, veo que pdf.js lo está haciendo mal ya que usa el modo estricto que no es compatible cuando se usa regenerator-runtime / babel. Por lo tanto, ya no es un problema aguas arriba porque las limitaciones están bien documentadas.

Veo 4 alternativas para resolver este problema:

• Usando una versión anterior de babel. La versión 2.1.266 de pdf.js no tiene este problema. fijar las versiones debería resolverlo. Esto debería ser lo más rápido.
• No use el modo estricto ya que las dependencias de babel no lo admiten.
• Desactive los complementos de transpile con el uso de regenerator-runtime. (https://caniuse.com/#feat=es6-generators)
• Proporcione dos versiones de pdfjs-dist. Uno para los navegadores antiguos (transpilado a ES5) y otro para los navegadores actuales. (transpilar a ES6)

Usando una versión anterior de babel. La versión 2.1.266 de pdf.js no tiene este problema. fijar las versiones debería resolverlo. Esto debería ser lo más rápido.

Anclar una dependencia a una versión anterior nunca es una buena idea, ya que puede causar problemas si hay errores de seguridad en las versiones anteriores de Babel. Además, el uso de versiones anteriores de una dependencia puede prevenir, retrasar y / o complicar la actualización de otras dependencias, causando así otros problemas.

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

Solo para aclarar: tenga en cuenta que la biblioteca PDF.js no está (actualmente) usando ninguna función de generador, sin embargo, async / await se está usando y es por eso que esta dependencia particular existe aquí.

Proporcione dos versiones de pdfjs-dist. Uno para los navegadores antiguos (transpilado a ES5) y otro para los navegadores actuales. (transpilar a ES6)

Esta parece ser la opción más realista de las sugerencias anteriores, pero no está claro cómo / cuándo sucederá en este momento (tenga en cuenta la discusión / problemas en PR # 11241).
Sin embargo, tenga en cuenta que solo se proporcionarán los siguientes tipos (generales) de compilaciones:

• Compilaciones solo compatibles con la última versión ES- {, cualquiera que sea en ese momento, es decir, los archivos compilados no se ejecutan a través de Babel y no se incluyen polyfills.
• Compilaciones que son compatibles con ES5, es decir, los archivos compilados son analizados por Babel y con polyfills incluidos.

Compilaciones solo compatibles con la última versión de ES- {versión}

¿Respetaría utilizar solo funciones / tecnologías compatibles con las 2 últimas versiones principales del navegador?

Una versión con funciones de propuestas de lenguaje de vanguardia que no sean compatibles con los navegadores más nuevos no nos ayudaría.

¿Respetaría utilizar solo funciones / tecnologías compatibles con las 2 últimas versiones principales del navegador?

Eso requeriría producir tres tipos diferentes de compilaciones, lo que no parece una gran idea. Por un lado, los usuarios probablemente estarían aún más confundidos en cuanto a qué compilación usar (ya que imagino que los usuarios no están seguros incluso con solo dos tipos de compilaciones). Además, intentar proporcionar varias compilaciones también supondrá una mayor presión, por ejemplo, relacionada con el soporte y el mantenimiento, para los pocos contribuyentes habituales de PDF.js.

Básicamente, la situación deseable en este caso en lo que a mí respecta sería que un usuario de la biblioteca:

• Elige la versión más reciente de ES y proporciona polyfills según sea necesario en función de las plataformas / navegadores que necesitan admitir.
• Elige la versión ES5 y obtiene todos los polyfills necesarios incluidos y el código es compatible con "todos" los navegadores modernos.

Una versión con funciones de propuestas de lenguaje de vanguardia que no sean compatibles con los navegadores más nuevos no nos ayudaría.

Hablando históricamente, no creo que hayamos comenzado a usar la funcionalidad inmediatamente cuando estuvo disponible, por ejemplo, en Firefox Nightly, por lo que no puedo prever que esto sea realmente un gran problema en la práctica.

Hola,

Me encontré con el mismo problema, la solución que utilicé fue cargar el tiempo de ejecución del regenerador en mi polyfill directamente.

De esta manera no cambié pdfjs-dist. Me permitió resolver mis problemas de CSP sin tener que volver a compilar pdfjs :)

@makidelille ¿

@makidelille ¿

usamos angularjs ( todavía ).

Para ser exactos, hemos creado un visor personalizado sobre pdf.js que se usa a través de una directiva angularjs

editar: el visor personalizado se construye con mecanografiado angularjs, por eso tenemos polyfills.

Recibo otro error inseguro en línea para el CSS, de esta línea de código:
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.

Hola,

Me encontré con el mismo problema, la solución que utilicé fue cargar el tiempo de ejecución del regenerador en mi polyfill directamente.

De esta manera no cambié pdfjs-dist. Me permitió resolver mis problemas de CSP sin tener que volver a compilar pdfjs :)

¿Usted (o alguien más) sabe cómo esta solución se traduciría en angular 2+? ¿Es posible arreglar esto?

Estoy usando esta biblioteca y me encuentro con el mismo problema de CSP (si lo desea, puede ver mi ticket en la lista de problemas de ese proyecto), pero este tipo de problemas con paquetes / npm / tipo de dependencia no es algo que entienda todo eso bien.

Desafortunadamente, la versión anterior de pdfjs que no tenía este problema (2.1.266, como se mencionó anteriormente) no parece ser compatible con esta biblioteca de envoltura angular 2+, y no parece tener una versión que use esa versión de pdfjs. internamente.

editar: Para cualquier persona en una situación similar a la mía, hay otra biblioteca de contenedor de pdfjs angular que funcionó para mí sin problemas de CSP. Vea aquí .

Creo que este problema se puede cerrar ahora, ya que la próxima versión contará con dos tipos de compilaciones:

• Una compilación moderna (para navegadores actualizados), que no se transpila con Babel y sin ningún polyfills incluido.
• Una compilación compatible con ES5 (se puede usar, por ejemplo, con IE11), que se transpila con Babel e incluye todos los polyfills necesarios.

¡Suena bien! Gracias @Snuffleupagus y todos trabajaron en esto: 1st_place_medal: