CSP Headerkonzept

[dergel]

Früher oder später kommen wir wohl an diesem Thema nicht vorbei. Umgang mit Headern in Verbindung mit AddOns etc.

Mein Vorschlag.

REDAXO selbst gibt ein sehr striktes Headerkonzept vor mit z.B. Kriterien wie diesen hier + liefert einen strikten CSP Header

Referrer-Policy same-origin';
X-XSS-Protection '0';
X-Content-Type-Options 'nosniff';
X-Frame-Options 'sameorigin';
Content-Security-Policy irgendwas sehr eingeschränktes

AddOns dürfen das aufweichen, aber man kann an einer Stelle im System einsehen welches AddOn was gemacht hat. Es gibt vielleicht Fälle redactor und Co, wo ein offeneres Konzept nötig ist. Das lässt sich auch als Individuelle Ausnahme auf eine page setzen.

Das Gleiche gilt fürs Frontend. Eventuell auch mit einer Wildcardlogik. Ich fände das im Core wichtig und als Basis, sonst kommen seltsame eigenständige Dinger zusammen (so wie ich gerade etwas baue) ..

Grundsätzklich interessant und gut? Ich würde auch einen PR liefern.

[dergel]

vielleicht könnte man es in der aktuellen Version optional über die Config aktivieren. Somit ist es BC + AddOns können sich darauf einstellen und alles anpassen.

[dergel]

Themen dazu. Cache-Control: no-store immer im Backend oder über config aktivierbar

Die Header in der backend.php besprechen die fest drin sind. z.B. auch der CSP

Vielleicht insgesamt eher auf CSP konzentrieren. Sehen wir das Issue hier vielleicht eher als Start für dieses Thema

[staabm]

CSP hat super viele varianten und parameter. ich denke man muss sich überlegen wie weit man hier gehen will und wie flexibel es sein muss um die ganzen sachen einzustellen (und es kommen auch immer wieder neue CSP parameter dazu).

auch kann man damit viel kaputt machen, bei falscher CSP... d.h. man muss nen guten kompromiss finden, dass sich leute mit wenig wissen darüber nicht ihre seite zerstören, aber die die wissen was sie tun auch "alles" machen können was sie wollen

auch ändern sich die empfehlungen für solche header des öfteren.
zum beispiel gab es eine zeit lang wo man empfohlen bekommen hat den xss auditor zu aktivieren: header('X-XSS-Protection: 1; mode=block');.
ein paar monate später hat sich herausgestellt dass in manchen browsern der auditor selbst sicherheitslücken hat und man somit die empfehlung geändert hat, dass man ihne aktiv deaktivieren soll mit 'X-XSS-Protection: 0':

[dergel]

Ich habe das oben etwas falsch formuliert. Ich rede vorwiegend über das Backend und im Frontend nur ein Hilfstool, um z.B. CSP Header konformer und sicherer erstellen zu können. Im Frontend sollte meines Erachtens keine Header fest sein.

Im Backend sehe ich einen gewissen festen Rahmen schon als wichtig, mit der Flexibilität diese individuelle aufweichen zu können.

@staabm Ist deine Aussage fürs front- und backend?

[staabm]

Meine aussage war mehr allgemein und ein bisschen in Richtung roll-out strategie (unabh. frontend/backend).

Ich denke eine CSP müsste opt-in sein am anfang sodass man erfahrung damit sammeln kann.

Auch das addon ökosystem müsste bzgl. CSP genug zeit haben um die "aufweichregeln" überall zu etablieren.

Man müsste das in mehreren schritten machen und nach und nach Erfahrungen sammeln.

An sich finde ich das feature aber wichtig

[alxndr-w]

Falls ihr eine Meinung dazu haben möchtet, wie das in der Praxis aussehen könnte.

Es gibt bei CSP einen Reporting-Modus. Man könnte im Backend loggen, welche Verletzungen auftreten und anfangs per Klick oder im Add-on via Core-Methoden ggf Domains erlauben.

Man könnte über die Package.yml diese Domains definieren.

Man könnte in einer Tabelle oder Einstellungsdatei loggen, welche Add-ons welche Domains erlauben möchten und beim deaktivieren oder deinstallieren auch wieder die Erlaubnis entziehen.

Im Frontend wäre es m.E. schlüssig, wenn ein Consent-Manager Möglichkeiten hat, Domains zur Laufzeit zu erlauben und zu verbieten. In letzter Konsequenz ist das der Ort, wo sich entscheidet, welche Drittanbieter-Domains etwas laden dürfen oder auch nicht. Und ich fände es charmant, wenn eine fehlende Einwilligung per CSP in Konsequenz das Laden von einer Domain verbietet.

[oioix]

Sorry, wenn ich mich hier einklinke, aber ich habe mich gezwungenermaßen einige Zeit in diesem Thema beschäftigt, weil mir die Sicherheit wichtig war und Angriffe inzwischen leider zum Alltag gehören.

Ich halte es für äußerst schwierig, das zentral konfliktfrei über Redaxo oder gar den Consent-Manager zu regeln.
Begründung:
Bei CSP wird außerdem eigentlich von Experten sogar dazu geraten, dass die CSP-directive für jede Seite gesondert konfiguriert sein sollte, um so wenig Angriffsfläche, wie möglich zu bieten. Z.B. sollte gem. dieser Strategie eine fremde Domain als Quelle für Kartenmaterial (z.B. Google oder openstreetmap) nicht auf Seiten als src erlaubt werden, die gar keine Karten enthalten.
Und nicht zu vergessen:
CSP-Directiven müssen eindeutig definiert sein und bestehende Directiven können nicht einfach ergänzt werden.

Wenn jetzt Redaxo die CSP-Directiven schreibt, wie soll man dann für anderen Content auf der Seite bzw. für die gesamte Site seine Directiven individuell an seine Bedürfnisse anpassen?
Nachdem es hier um Sicherheit geht , welche in der Verantwortung des Admins steht (!), sollte die individuelle Einstellungsmöglichkeit für den Admin absolut oberste Priorität haben.

Ich persönlich definiere die CSP-Directive inzwischen ganz gerne in der boot.php des Projekt-Addon, weil ich es hier gut editieren und individuell Seiten zuweisen kann. Auch Frontend/Backend kann ich von hier aus gut steuern. Also vorn hier aus alles möglich (nicht so im Template oder der htaccess).

Die übrigen (nicht CSP) Header, wie z.B. ...

Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set X-Frame-Options "sameorigin"
Header set X-XSS-Protection "1; mode=block"
Header set X-Content-Type-Options "nosniff"
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
...

... sind meines Erachtens am besten in der zentralen .htaccess aufgehoben, weil sie dann auch wirklich alle Transfers überspannen.

Begründung:
Ich hatte bei Überprüfung der Website mit ZAP festgestellt, dass z.B. der HSTS-Header dann nicht für alle übertragenen Dateien (css, js, Bilder) aktiviert ist, wenn man HSTS in der config.yml aktiviert. Aktiviert man es aber in der .htaccess ist es für alle Dateien aktiv. Hat man es sowohl in der config.yml als auch in der .htaccess aktiviert, kann man mit Browsern wie Edge Probleme bekommen (Warnung: "Sie besuchen eine Seite mit gefährlichem Inhalt").

[alxndr-w]

Bei CSP wird außerdem eigentlich von Experten sogar dazu geraten, dass die CSP-directive für jede Seite gesondert konfiguriert sein sollte, um so wenig Angriffsfläche, wie möglich zu bieten.

Das spricht dann für REDAXO, weil das CMS eher weiß, was erlaubt sein sollte, als der Webserver oder pauschal die htaccess (und die gilt nur in Apache-Umgebung, nicht nginx)

Wenn jetzt Redaxo die CSP-Directiven schreibt, wie soll man dann für anderen Content auf der Seite bzw. für die gesamte Site seine Directiven individuell an seine Bedürfnisse anpassen?

Via Extension Point, schätze ich.

sollte die individuelle Einstellungsmöglichkeit für den Admin absolut oberste Priorität haben.

Es wurde doch noch gar nicht über die Form der Implementierung entscheiden, zumindest sehe ich hier nichts.

Eine hohe Priorität könnte einfach auch haben, einen Weg zu finden, wie Admins ohne deinen oder meinen Wissensstand dazu kommen, ein möglichst sicheres REDAXO zu betreiben. Deswegen geht's hier doch gar nicht um ein "entweder-oder*, sondern m.E. um eine passende Umsetzung.

[oioix]

Das spricht dann für REDAXO, weil das CMS eher weiß, was erlaubt sein sollte, als der Webserver oder pauschal die htaccess (und die gilt nur in Apache-Umgebung, nicht nginx)

Ja stimmt. Genau deshalb hab ich mich diesbezüglich für die boot.php im Projekt-Addon entschieden. Ganz am Anfang hatte ich es in der htaccess und das war nicht der beste Ort.

Via Extension Point, schätze ich.

Ich denke, dass nur die wenigsten wissen, wie man Extension Points nutzt. Ich nutzte EPs an vielen Stellen (insbesondere OutputFilter), finde die Nutzung teils dennoch etwas kompliziert und habe mich schon häufig gefragt, ob es nicht auf die Performance geht, wenn man viele EPs gleichzeitig nutzt.

Es wurde doch noch gar nicht über die Form der Implementierung entscheiden, zumindest sehe ich hier nichts.

Schon klar. Ich habe es als eine ergebnisoffene Diskussion verstanden.

Eine hohe Priorität könnte einfach auch haben, einen Weg zu finden, wie Admins ohne deinen oder meinen
Wissensstand dazu kommen, ein möglichst sicheres REDAXO zu betreiben

Eben deshalb habe ich mich hier gemeldet. Für jemanden, der sich noch nicht damit beschäftigt hat, ist CSP (genauso wie die anderen Sicherheits-Header) ein komplexes Thema. Man findet viel Knowhow im Internet, aber die Beschreibungen, lassen oft noch Fragen offen. Es gibt nur wenige gute und vollständige Quellen.
Gute CSP-Direktiven kann man nur erstellen, wenn man weiß, was man tut. Immerhin kann man mit einer aktiven, falsch konfigurierten Direktive auch Kunden von bestimmten Features aussperren (das ist mir passiert) und merkt es nicht, wenn sich der Kunde nicht meldet und man sich keine Reports per E-Mail zukommen lässt. Man sollte Direktiven deshalb auch erst mal eine Weile testen, bevor man sie scharf stellt.
Vielleicht wäre eine KnowHow-Seite auf Redaxo mit der Nennung von weiterführenden Links eine Idee.
Die eine richte CSP-Direktive gibt es nicht. Es ist eine individuelle Einstellungssache die zum eigenen Anwendungsfall passen muss.

Ein eigenes Addon könnte eine gute Lösung sein. Das könnte man einfach deaktivieren.
Wenn man alle Optionen von CSP ordentlich und flexibel genug abbilden möchte, wäre das aber vermutlich kein simples Addon.
Wenn so ein Addon für einem unerfahrenen CSP-Nutzer sinnvoll sein soll, müsste es sicher auch die Einstellngsmöglichkeiten und die Folgen für die Sicherheit erklären.

Auch mit den anderen Headern sollte man sich als Redaxo-Admin ein klein wenig auskennen wenn man sie nutzt, denn nicht für jeden Anwendungsfall ist jeder Header geeignet und auch bei den Headern kann man teilweise verschiedene Optionen wählen. Wenn man headers einfach nutzt, ohne zu wissen was sie machen, wundert man sich vielleicht, warum bestimmte Dinge nicht so wie früher funktionieren..

[alxndr-w]

Vielleicht wäre eine KnowHow-Seite auf Redaxo mit der Nennung von weiterführenden Links eine Idee.

https://github.com/FriendsOfREDAXO/tricks/tree/master/_docs/development na dann los :) Ich würde mich zum Korrekturlesen anbieten. Du kannst ja auch mal deine Variante aus der boot.php veröffentlichen, damit schon mal ein aktueller Lösungsansatz bereitsteht.

(würde ich aber nicht weiter hier im Issue diskutieren, sonst gehen wir den anderen noch auf den 🍪)

Ich habe mich auch lange gegen EPs gesträubt, die sind auch nach wie vor einer der schlecht dokumentierten Anteile hier in REDAXO - und manche finden dort statt, wo nicht mal ein dump() eine Ausgabe erzeugt. Dennoch sind die grundsätzlich ja das Mittel der Wahl, um ein vom Core vorgesehenes Verhalten zu überschreiben und mit entspr. Beispielcode auch copy-paste-fertig.

(sorry für Off-Topic @dergel)

[oioix]

Danke für die Anregung. Bei meinem ersten gut gemeinten PR vor ich glaube etwas 2 Jahren (Consent Manager) hat man mich etwas rüde abgewatscht. Ich wusste damals nicht, dass man vorher fragen muss. Hab mich seitdem nicht mehr mit Pull requests beschäftigt und müsste mich da erst mal neu reindenken.
Aktuell habe ich mehrere Projekte gleichzeitig zu betreuen und entsprechend wenig Zeit für Neues. Ich teile aber gerne was ich weiß, sobald ich wieder Luft habe und mit PRs vertraut bin. md ist außerdem auch ein Format mir dem ich mich so gut wie nicht beschäftigt habe.

Es gibt offenbar schon eine Section zum CSP wie ich gerade gesehen habe. Allerdings nicht sehr ausführlich und ohne Beispiel, wie man es einfach in Redaxo einbinden kann. Der dortige Link zum CSP-Generator ist inzwischen kostenpflichtig.
https://github.com/FriendsOfREDAXO/tricks/blob/master/_docs/howto/sicherheitstipps.md

Auf die Schnelle kann ich diesen, wie ich finde sehr nützlichen Link beitragen.
https://csp-evaluator.withgoogle.com/

Man kann dort seine CSP bzgl. älterer und neuerer Browser checken (CSP 1 bis 3). Hat mir sehr sehr dabei geholfen, schnell die individuell zur für mich richtigen Einstellung zu finden, wenn auch nicht alle vorgeschlagenen Optimierungsmaßnamen am Ende tatsächlich für meinen Fall perfekt waren.

Das ist ein Checker, kein Generator. Aber es gibt dort sowohl ein Positiv-/Negativbeispiel als Einstiegshilfe.

[dergel]

Ich möchte das Thema noch mal aufrollen und unterscheide stark zwischen Front- und Backend. Im Frontend ist es sehr individuell und ist für mich in diesem Schritt nicht das Thema. Es geht um das Backend. Dort würde ich gerne sehr restriktive Einstellungen haben (kein unsafe-inline und unsafe-eval z.B.), die ein einzelnes AddOn dann für sich aufweichen kann. Mir geht es darum, dass man damit einen gewissen Stil in den AddOns mit etabliert. Keine Inline Styles, keine Scripte die unkontrolliert ausgeführt werden. AddOns können dann Domain ergänzen, unsafe an den benötigten Stellen erlauben. Wir haben nun nonces ergänzt und somit eine wichtige Ergänzung drin. Man könnte diese Einstellung auch optional in der config zunächst ergänzen.

roll-out-Strategie :)

• CSP Logik/Klassen ergänzen
• Config Option für Aktivierung mit aufnehmen
• AddOn Entwickler darauf hinweisen und eigene AddOns testen lassen
• Eventuelle Probleme einarbeiten.
• Version x+ dann config auf aktiv.

[alxndr-w]

Ich biete an, das mit ein paar Add-ons zu testen, die aktuell auch unsafe-inline und unsafe-eval verwenden, wenn es soweit ist und Dokumentation dazu in Reinform zu bringen.

Bitte dann mich direkt ansprechen, Issues-Diskussionen gehen bei mir manchmal einfach unter.

[gharlan]

Keine Inline Styles

Inline-Skripte vermeiden, ist machbar (aber gibt vermutlich auch schon einige Todos in REDAXO).

Inline Styles halte ich für schwieriger. Habe ich bisher nie geschafft in meinen Projekten, ganz drauf zu verzichten. Ärgerlich ist vor allem auch, dass man bei style="..." gar keine Möglichkeit hat, eine nonce zu setzen.

Problematisch sind vor allem auch so Dinge wie Dropdowns, Modals etc. Die setzen ja sehr oft je nach Situation an den aufpoppenden Container irgendwelche position-Werte etc per style-Tag.

Aber auch in eigenem Code kommt es häufiger vor, dass man doch Inline-Styles nutzen möchte. Um eine spezifische Breite oder so anzugeben. Oder ein dynamisches Hintergrundbild zu setzen. Oder zunehmend auch, um CSS-Variablen zu setzen, wobei wir das in REDAXO so bisher glaube ich nicht nutzen.
(Zu dem letzten Punkt, CSS-Variablen, gibt es eine Diskussion, ob man eine separate CSP-Einstellung unsafe-variables dafür einführt: w3c/webappsec-csp#174)

[alxndr-w]

Problematisch sind vor allem auch so Dinge wie Dropdowns, Modals etc. Die setzen ja sehr oft je nach Situation an den aufpoppenden Container irgendwelche position-Werte etc per style-Tag.

Zur Laufzeit erstellt sollte eigentlich kein Problem sein, es geht meines Wissens nur um die initial im Quellcode übergebenen.

[gharlan]

Ah interessant, das wusste ich noch nicht. Das erleichtert die Sache auf jeden Fall schon mal.
Wird hier auch bestätigt: https://stackoverflow.com/a/29089970
Wichtig ist aber somit, dass CSSOM genutzt wird, und nicht der style-tag raw gesetzt wird.

[oioix]

Ich habe das Thema bisher aus zeitlichen Gründen nicht weiterverfolgen können und kann mich auch aktuell nicht einklinken. Wollte aber dies kurz beitragen...

Wie ich anderer Stelle schon geschrieben hatte, gibt es leider Plugins man auch aufgrund der Programmierung selbst mit einem nonce nicht in den Griff bekommt. Konkret Symphony: symfony/symfony#49068 (comment)

Mit der CSP-report-Funktion lässt sich das ganz gut untersuchen. Man muss dazu eine öffentliche erreichbare Seite einrichten, wo der Report empfangen und verarbeitet wird (z.B. mail-Mitteilung).

Abgesehen davon stell sich die Frage wie mit Funktionen/Code umgegangen werden müsste, die sowohl in der Backend-, wie auch in einer Frontendumgebung laufen sollen. Ist mir nur so als ein möglicher Punkt eingefallen. Ich hab mich damit nicht weiter beschäftigt.