Pdf.js: CSP-Verstöße für unsicher-inline in [email protected]

Die Richtlinie wird durch diese Zeile in v2.2.228 verletzt Function("r", "regeneratorRuntime = r")(runtime);

Dabei handelt es sich nicht um Code, der irgendwo in der PDF.js-Bibliothek selbst entstanden ist, sondern aus einem Babel-Polyfill, das benötigt wird, um async / await in älteren Browsern zu unterstützen. Daher ist leider überhaupt nicht klar, was (wenn überhaupt) hier dagegen unternommen werden könnte .

Ja, ich denke, dies sollte stattdessen stromaufwärts gemeldet werden.

@timvandermeij Code in pdf.js könnte so geschrieben werden, dass das Polyfill nicht benötigt wird.
@Snuffleupagus Irgendwelche Hinweise auf die Datei, die Sie sich ansehen sollten?

Habe tiefer hineingeschaut. Keine Chance :-(

Hier ist das Problem regenerator-runtime/runtime.js .

Gleiches Problem hier.

@Snuffleupagus ist es möglich, 2 separate Dateien zu verteilen, eine für den älteren Browser und eine zweite für die immergrünen Browser?

Gibt es ein Problem im Upstream zu verfolgen? Stehe aktuell vor dem gleichen Problem

Sie können das Problem an https://github.com/facebook/regenerator melden

Es sieht so aus, als hätten die Autoren von pdf.js dieses Problem hier behoben

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

aber aufgrund von Problemen mit Babel mussten sie es zurücksetzen

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

Es sieht so aus, als hätten wir hier eine Sackgasse. Ich sehe hier drei Lösungen:

• Warten Sie, bis facebook/regenerator die Probleme behoben hat.
  Es mag am klarsten sein, aber viele Benutzer werden bei einer alten Version von pdf.js bleiben
• Downgrade facebook/regenerator (vielleicht muss auch Babel herabgestuft werden)
• Stellen Sie zusätzlich zum aktuellen ES5 eine Evergreen-Version (ES2016+) von pdf.js bereit, die facebook/regenerator nicht benötigt. (Viele aktuelle Webanwendungen mussten nicht ES5-kompatibel sein).

Wie auch immer, die CSP-Verletzung ist hier gut dokumentiert
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);

Das heißt, wenn Sie eine CSP-Verletzung haben, sollten Sie dies nicht im strikten Modus ausführen. Da dies ein bekanntes Verhalten in der Regenerator-Laufzeit ist, sollte pdf.js den Strict-Modus ausschalten.

@timvandermeij Können Sie den Kommentar bitte noch einmal lesen, wenn es eine Aufgabe für pdf.js gibt oder nicht?

Ich sehe nicht wirklich, was PDF.js hier anders machen könnte. Obwohl der Kommentar klar ist, führen wir PDF.js absichtlich im strikten Modus aus, um Fehler zu vermeiden und Optimierungen zu ermöglichen. Da dies vorher nicht passiert ist und wir facebook/regenerator nicht einmal direkt verwenden (sondern nur als Abhängigkeit von einem anderen Paket), würde ich sagen, dass diese gepatcht werden sollten, es sei denn, wir können eine triviale Änderung vornehmen. auf unserer Seite tun müssen, aber ich weiß nicht, was das dann wäre...

@timvandermeij

Danke, dass du es herausgefunden hast.

Wie wäre es mit einer babel-freien Version von pdf.js? Moderne Browser sollten kein Regenerator-Laufzeit-Polyfill benötigen.

@jkroepke Im Idealfall würden wir Babel überhaupt nicht verwenden, aber leider ist es

Ich habe das gleiche Problem mit 2.3.200. Irgendein Workaround oder Fixes? Vielen Dank.

@timvandermeij

Am Ende sehe ich, dass pdf.js es falsch macht, da es den strikten Modus verwendet, der bei Verwendung von regenerator-runtime/babel nicht unterstützt wird. Es ist also kein Upstream-Problem mehr, da die Einschränkungen gut dokumentiert sind.

Ich sehe 4 Alternativen, um dieses Problem zu lösen:

• Eine ältere Version von Babel verwenden. Die Version 2.1.266 von pdf.js hat dieses Problem nicht. Das Anheften der Versionen sollte behoben werden. Dies sollte am schnellsten sein.
• Verwenden Sie den strikten Modus nicht, da die Abhängigkeiten von babel ihn nicht unterstützen.
• Deaktivieren Sie die Transpile-Plugins mit regenerator-runtime. (https://caniuse.com/#feat=es6-generators)
• Stellen Sie zwei Versionen von pdfjs-dist bereit. Eine für alte Browser (übertragen auf ES5) und eine für die aktuellen Browser. (übertragen auf ES6)

Eine ältere Version von Babel verwenden. Die Version 2.1.266 von pdf.js hat dieses Problem nicht. Das Anheften der Versionen sollte behoben werden. Dies sollte am schnellsten sein.

Eine Abhängigkeit an eine alte Version anzuheften ist nie eine gute Idee, da dies zum Beispiel Probleme verursachen kann, wenn es Sicherheitslücken in älteren Babel-Versionen gibt. Darüber hinaus kann die Verwendung älterer Versionen einer Abhängigkeit die Aktualisierung anderer Abhängigkeiten verhindern, verzögern und/oder erschweren, wodurch andere Probleme verursacht werden.

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

Nur zur Verdeutlichung: Bitte beachten Sie, dass die PDF.js-Bibliothek (derzeit) keine Generatorfunktionen verwendet, jedoch async / await verwendet wird und deshalb diese spezielle Abhängigkeit hier existiert.

Stellen Sie zwei Versionen von pdfjs-dist bereit. Eine für alte Browser (übertragen auf ES5) und eine für die aktuellen Browser. (übertragen auf ES6)

Dies scheint die realistischste Option aus den obigen Vorschlägen zu sein, aber wie / wann dies geschehen wird, ist zu diesem Zeitpunkt nicht klar (beachten Sie die Diskussion / Probleme in PR #11241).
Beachten Sie jedoch, dass dann nur die folgenden (allgemeinen) Arten von Builds bereitgestellt werden:

• Builds nur kompatibel mit der aktuellsten ES-{Version}, was auch immer diese gerade sein mag, dh die Build-Dateien werden nicht durch Babel ausgeführt und es sind keine Polyfills enthalten.
• Builds, die ES5-kompatibel sind, dh die erstellten Dateien werden von Babel geparst und mit Polyfills versehen.

Builds nur kompatibel mit der neuesten ES-{version}

Würden Sie es respektieren, nur Funktionen/Technologien zu verwenden, die von den 2 neuesten Browserversionen unterstützt werden?

Eine Version mit superaktuellen Sprachvorschlägen, die von neueren Browsern nicht unterstützt wird, würde uns nicht weiterhelfen.

Würden Sie es respektieren, nur Funktionen/Technologien zu verwenden, die von den 2 neuesten Browserversionen unterstützt werden?

Dazu müssten drei verschiedene Arten von Builds erstellt werden, was keine gute Idee zu sein scheint. Zum einen wären die Benutzer wahrscheinlich noch verwirrter, welchen Build sie verwenden sollen (da ich mir vorstelle, dass Benutzer selbst bei nur zwei Arten von Builds unsicher sind). Darüber hinaus wird der Versuch, mehrere Builds bereitzustellen, die wenigen regulären PDF.js-Mitwirkenden stärker belasten, z. B. in Bezug auf Support und Wartung.

Grundsätzlich wäre die für mich wünschenswerte Situation in diesem Fall, dass ein Bibliotheksbenutzer entweder:

• Wählt den neuesten ES-Build aus und stellt bei Bedarf selbst Polyfills bereit, je nachdem, welche Plattformen/Browser sie unterstützen müssen.
• Wählt den ES5-Build aus und erhält alle erforderlichen Polyfills und Code, der mit "allen" modernen Browsern kompatibel ist.

Eine Version mit superaktuellen Sprachvorschlägen, die von neueren Browsern nicht unterstützt wird, würde uns nicht weiterhelfen.

Historisch gesehen glaube ich nicht, dass wir jemals angefangen haben, Funktionen sofort zu verwenden, als sie zB in Firefox Nightly verfügbar waren, daher kann ich nicht vorhersehen, dass dies in der Praxis tatsächlich ein großes Problem darstellt.

Hi,

Ich bin auf das gleiche Problem gestoßen, die Lösung, die ich verwendet habe, bestand darin, die Regenerator-Laufzeit von meinem Polyfill direkt zu laden.

Auf diese Weise habe ich pdfjs-dist nicht geändert. Dadurch konnte ich meine CSP-Probleme lösen, ohne pdfjs neu kompilieren zu müssen :)

@makidelille Benutzt du eckig?

@makidelille Benutzt du eckig?

wir verwenden anglejs ( still ).

Um genau zu sein, haben wir einen benutzerdefinierten Viewer auf pdf.js erstellt, der durch eine anglejs-Direktive verwendet wird

Bearbeiten: Der benutzerdefinierte Viewer wird mit Typoscript-Angularjs erstellt, deshalb haben wir Polyfills.

Ich erhalte einen weiteren unsicheren Inline-Fehler für das CSS aus dieser Codezeile:
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.

Hi,

Ich bin auf das gleiche Problem gestoßen, die Lösung, die ich verwendet habe, bestand darin, die Regenerator-Laufzeit von meinem Polyfill direkt zu laden.

Auf diese Weise habe ich pdfjs-dist nicht geändert. Dadurch konnte ich meine CSP-Probleme lösen, ohne pdfjs neu kompilieren zu müssen :)

Wissen Sie (oder jemand anderes), wie sich diese Lösung in Winkel 2+ übersetzen würde? Ist es möglich, dies zu beheben?

Ich verwende diese Bibliothek und stoße auf das gleiche CSP-Problem (wenn Sie möchten, können Sie mein Ticket in der Liste der Projektprobleme sehen), aber diese Art von Problemen mit Paketen/npm/Abhängigkeitstypen ist nichts, was ich alles verstehe Gut.

Leider scheint die alte Version von pdfjs, die dieses Problem nicht aufwies (2.1.266, wie oben erwähnt), nicht mit dieser Angular 2+ Wrapper-Bibliothek kompatibel zu sein, und es scheint keine Version zu geben, die diese Version von pdfjs verwendet im Inneren.

Bearbeiten: Für jeden, der sich in einer ähnlichen Situation wie ich befindet, gibt es eine andere eckige pdfjs-Wrapper-Bibliothek, die für mich ohne CSP-Probleme funktioniert hat. Siehe hier .

Ich glaube, dass dieses Problem jetzt geschlossen werden kann, da die kommende Version zwei Arten von Builds enthalten wird:

• Ein moderner Build (für aktuelle Browser), der nicht mit Babel transpiliert ist und ohne enthaltene Polyfills.
• Ein ES5-kompatibler Build (kann zB mit IE11 verwendet werden), der mit Babel transpiliert wird und alle notwendigen Polyfills enthält.

Hört sich gut an! Danke @Snuffleupagus und alle haben an dieser :1st_place_medal mitgearbeitet: