Content Security Policy implementieren

feedback
Tags: #<Tag:0x00007fc18acc7d30>

#1

Das Einbinden externer Inhalte in Discourse führt, wie bereits beim alten Forum, zu Mixed Content Fehlern.
Darum schlage ich vor, eine restriktive CSP auszuarbeiten und zu implementieren. Dies dürfte hier wesentlich einfacher umzusetzen sein, als die Seiten, die noch von unseren alten Proxy abhängig sind.


Onebox-Vorschau
#2

Hallo Jowi

https://basisentscheid.piratenpad.de/PRT-2017-04-02

ich habe dein Anliegen an die nächste Televotia Sitzung eingetraten. Du darfst gerne teilnehmen wenn du möchtest.


#3

Discourse selbst unterstützt noch keine CSP:

https://meta.discourse.org/t/how-to-configure-content-security-policy/53308

Ein Problem ist, dass noch inline-Skripte und andere Dinge verwendet werden, für die es Ausnahmen braucht. Wir können natürlich im nginx vor dem Docker-Container den Header hinzufügen, müssen dabei aber aufpassen keine erwünschte Funktionalität kaputt zu machen. Am Anfang werde ich es mal mit Content-Security-Policy-Report-Only versuchen. Damit werden die Verstöße gegen die Policy nur gemeldet. Ich logge das dann mit.

Das hier habe ich schon ein wenig getestet:

Content-Security-Policy-Report-Only:"default-src 'self' https://*.piratenpartei.ch 'unsafe-inline' 'unsafe-eval'

Das würde alle externen Zugriffe verbieten. Da wir selbst nur HTTPS machen, ist HTTP damit komplett ausgeschlossen. Die Vorschaubilder in den Oneboxes gehen damit auch nicht mehr. Piraten-Domains können wir als Ausnahme erlauben, denke ich.

Content Security Policy-Referenz


#4

Selbstverständlich muss die CSP im nginx konfiguriert sein. Ansonsten könnte bei einer kritischen Lücke in Discourse auch die CSP von Discourse kompromittiert werden.

Das https://*.piratenpartei.ch ist besser als nichts, aber es gibt ein Aber:

  • Wir haben ziemlich viele Subdomains, ich würde nicht allen trauen
  • Wir haben zusätzlich noch diverse Domain Aliase

Um die OneBox mache ich mir persönlich weniger sorgen als um aktive Inhalte. 'unsafe-inline' und 'unsafe-eval' sind natürlich doof, ich hoffe da unternimmt Discourse noch was dagegen. Gleiches hoffe ich bzgl. SRI. [1][2]

Hier noch einige, wo ich erwarten würde, dass sie unproblematisch sind:

  • child-src 'none' oder child-src 'self', wenn möglich mit sandbox
  • disown-opener
  • form-action 'self'
  • frame-src 'none' oder frame-src 'self' (legacy)
  • frame-ancestors 'none' oder frame-ancestors 'self'
  • object-src 'none' oder object-src 'self'
  • plugin-types 'none'
  • reflected-xss block
  • referrer no-referrer oder referrer origin (siehe auch [3]) (Legacy, siehe auch Referrer-Policy Header [4])
  • upgrade-insecure-requests oder block-all-mixed-content
  • worker-src 'self'

Im besten Fall haben wir default-src 'none' und dann Einzelne gezielt erlaubt.

[1] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/require-sri-for
[3] ID Server verlangt nach Referrer
[4] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy


#5

Die Test-CSP ist aktiv und wird geloggt. Wer selbst sehen will, welche Verstöße es gibt, kann sich die Meldungen in der Konsole der Entwickler-Tools im Browser ansehen.

Aktuell aktiviert:

  default-src 'self' 'unsafe-inline' 'unsafe-eval'
  child-src 'none'
  frame-ancestors 'none'
  object-src 'none'
  form-action 'self'
  block-all-mixed-content

worker-src, disown-opener und reflected-xss kennen weder Chrome 57 noch Firefox 52