dump() -> CSP-violation - (directive 'style-src') #5503
Comments
|
Wir nutzen die Ich sehe nicht, wie wir da, von REDAXO aus, sinnvoll etwas tun können. Hast du eine Idee? |
|
Hmm, die von mir verlinkte Zeile sollte eigentlich kein Problem sein: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/style-src
Kannst du nochmal schauen, um welches style-Attribut es bei dir genau geht? Also was steht im style-Attribut? |
|
Achso, kann es sein, dass es um |
|
Du kannst während der Entwicklung dem Browser mitteilen, CSP zu ignorieren bzw den Header zu modifizieren, z.B. über eine Browser-Erweiterung. Z.B.: https://chrome.google.com/webstore/detail/redirect-url-modify-heade/mdnleldcmiljblolnjhpnblkcekpdkpa Vielleicht bietet Firefox auch eine eigene Möglichkeit. Eine andere Möglichkeit könnte sein, wenn REDAXO den Header überschreibt, solange der Entwickler-Modus aktiv ist oder man als Admin eingeloggt ist. Schön wäre das jedoch nicht, denn als Entwickler will man doch möglichst nah das Live-Verhalten haben bei sowas, denke ich. @oioix eine separate Entwicklungsinstallation mit eigenen CSP-Einstellungen kommt nicht infrage? |
Verstehe. Ich dachte das wäre eine Eigenentwicklung. ;-)
Das Problem ist, dass der gesamte JS-Code in der Frontendausgabe in einer Zeile steht. Die Positionsangaben 554 und 691 sind zwar klar, aber wenn ich mir diese beiden Stellen mit dem Editor anzeigen lasse werde ich nicht schlau daraus, wie das Style hier genau erzeugt wird. An den beiden Stellen 554 und 691 die der CSP-Report angibt findet sich beides mal dieses:
Es sieht so aus, als ob wird ein Der CSP-Report gibt bei Stelle 554 als Sample aus (siehe auch rotes Bild oben): Und das passt exakt zum JS-Code in der Frontend-Ausgabe: Mehr konnte ich nicht heraus bekommen. |
Es gibt schon einen Weg. Man kann die Ausgabe an einen Backend-Login knüpfen. Nur ist es so, dass ich die CSP-Direktive extra aufgrund eines konkreten Alasses verschärft hatte, weil ich gerade während der Entwicklung einer oath-Schnittstelle bei einem großen Anbieter (also mit einem Backend-Login) im Zuge einer oauth-Atthentifizierung bei der Rückkehr von der Anbieterseite immer wieder aus Redaxo ausgeloggt wurde. Trotz RememberMe wohl gemerkt. Eine XXS-Attacke auf die Session war nicht komplett auzuschließen. Die CSP-Direktive abzuschalten oder unsicherer zu gestalten wäre in einer solchen Situation dann wohl eher keine gute Idee. ;-) |
Danke für den Link. Die betreffende Stelle steht dort im Code in Zeile 160. Die Frage ist allerdings wie. Die haben keinen Issue-Bereich, wo man was posten könnte. |
|
Danke. Ich werde es dort posten. |
|
Hab es dort gepostet. Kann hier geschossen werden. ;-) |
REDAXO: 5.14.2
PHP: 8.1
Browser: Firefox
dump() ist ja ein super praktisches Tool zum debuggen.
Das dump-Fenster wird offenbar über ein JS
<script> Sfdump = window.Sfdump ...erzeugt.Die Verwendung von CSP zum Schutz der Website gegen XSS wird inzwischen immer wichtiger.
Nach der Umstellung auf eine striktere CSP Direktive, die mit Nonce arbeitet und aus Sicherheitsgründen keine
unsafe-inlinemehr zulässt, gibt es nun im Frontend mitdump($meinCode)bei jedem Reload zwei CSP-Violations mit entsprechendem (E-Mail-/Log-Report).<script>und<style>kann man automatisch über den output-filter mit einem Nonce versehen. Das ist problemlos lösbar. Mit diesen beiden Tags und deren Inhalt gibt es so gelöst keine Probleme.Es gibt aber offensichtlich im
dump($meinCode)-Code zwei Stellen (Zeichenpositionen 554 und 691), wo noch anderes Inline-CSS verwendet wird (also nicht innerhalb eines<style>-Tag, sondern vermutlichstyle=""welches möglicherweise per innerHTML eingefügt wird). Inline CSS mitstyle=""kann leider nicht mit einem Nonce legitimiert werden. Mit einemclass=""wäre dies vermeidbar.Abgesehen von der CSP-Violoation-Meldung kommt mit dem
dump($meinCode)in der Konsole auch die (gelbe) Meldung:The text was updated successfully, but these errors were encountered: