Inline Styles unsicher?

[Michael_K]

Hallo,

sofern ein HTML-String/Code-Fragment aus dritter (unbekannter) Quelle softwaretechnisch übernommen wird, ist stets sicherzustellen, dass die Daten vor Einbindung in die eigene Umgebung/Webseite "gesäubert" werden, um Schadcode fernzuhalten. Sanitizer können aber nicht davor schützen, dass Inline-Styles böswillig den Nutzer optisch täuschen oder etwas vorgaukeln.

Sollte man dann deshalb gleich die ganzen Inline-Style aus dem HTHML-Code aus dritter Quelle entfernen? Mit den CSP-Einstellungen für style-src unsafe-inline verbieten ist ja nur sinnvoll, wenn man im eigenen HTML nicht auch Inline-Styles verwendet (aus welchen Gründen auch immer) und nicht auf iframes etc zurückgreifen kann.

Gibt es hierzu irgendwo Erläuterungen, die das Problem verständlich skizzieren? Gibt es ggfs. auch eine Web-Seite, die veranschaulicht, wie sich die unterschiedlichen CSP setting für style-src auf die Darstellung auswirken? Oder kann man das gar im Browser für eine Webseite simulieren (ich habe keine Einstellung in den Entwicklertools gefunden)?

Mir ist das Thema Inline-Styles und die Problematik bekannt, aber ich würde gern dazu eine Demo geben. (... ich könnte natürlich auch am eigenen Server so etwas basteln, aber das kostet zuviel Zeit).

Gruss Michael

[MrMurphy]

Kann es sein das du eine "Gefahr" siehst, die es überhaupt nicht gibt?

Deine Angaben kann ich nicht nachvollziehen. Meinst du wirklich HTML und CSS? Die bilden ganz allgemein und grob eine Seitenbeschreibung. Da kann kein Schadcode enthalten sein, weder inline noch inside noch extern.

Oder meinst du Javascript, PHP und Konsorten?

Wenn du (aus welchen unerfindlichen Gründen auch immer) unsichere Seiten testen willst kannst du als eine Möglichkeit einfach einen virtuellen Rechner ohne Außenverbindung aufsetzen. Da braucht es keine speziellen Browsereigenschaften.

Vielleicht habe ich dich auch komplett falsch verstanden.

[Auge]

Hallo

Kann es sein das du eine "Gefahr" siehst, die es überhaupt nicht gibt?

…

Vielleicht habe ich dich auch komplett falsch verstanden.

Soweit ich ihn verstanden habe, geht es um willentlich aus externen Quellen hinzugeladenen HTML-Code. Bei dem kann, so die Befürchtung, über Inline-CSS ein falscher Eindruck über Herkunft und Funktion beim Seitenbesucher erzeugt werden.

Falls Michael doch etwas anderes meint, muss er das genauer ausführen.

Tschö, Auge

[Michael_K]

Hallo,

Soweit ich ihn verstanden habe, geht es um willentlich aus externen Quellen hinzugeladenen HTML-Code. Bei dem kann, so die Befürchtung, über Inline-CSS ein falscher Eindruck über Herkunft und Funktion beim Seitenbesucher erzeugt werden.

Genau darum geht es. Mit viel Geschick kann dem Nutzer etwas anderes vorgetäuscht werden und somit für Phishing & Co misbraucht werden. (Hinweis: Die CSP im selfhtml.org header erlauben ja auch explizit unsafe-inline CSS).

Gruss Michael

[Felix Riesterer]

Lieber Michael_K,

(Hinweis: Die CSP im selfhtml.org header erlauben ja auch explizit unsafe-inline CSS).

und von wo wird dieses „unsafe-inline CCS“ ausnahmslos geladen? Richtig, von einer SELFHTML-Subdomain. Es ist also mitnichten ein Sicherheitsproblem. Würden unsere Header strenger eingestellt, würden die Wiki-Beispiele mit entsprechenden Features nicht mehr funktionieren. Will man das?

Liebe Grüße

Felix Riesterer

[Felix Riesterer]

Lieber Michael_K,

sofern ein HTML-String/Code-Fragment aus dritter (unbekannter) Quelle softwaretechnisch übernommen wird,

bitte beschreibe das Szenario hinreichend genau, bei dem der String-Wert von Quelle Q zu Ziel Z „übernommen“ wird. Wenn Du das nicht präzisierst, ist der Rest der Debatte sinnlos.

ist stets sicherzustellen, dass die Daten vor Einbindung in die eigene Umgebung/Webseite "gesäubert" werden, um Schadcode fernzuhalten.

Was genau ist mit „Schadcode“ gemeint? Reden wir von manipulierten Daten, die das System des Seitenbesuchers durch dort ungepatchte Lücken angreifen? Oder reden wir von manipulierten Daten, die dafür sorgen, dass ein Besucher auf dem Webserver plötzlich Dinge tun kann, weil das verwendete CMS/Blog/whatever dadurch angegriffen wird?

Sanitizer können aber nicht davor schützen, dass Inline-Styles böswillig den Nutzer optisch täuschen oder etwas vorgaukeln.

Das ist in meinen Augen auch nicht die Aufgabe von Sanitizern, sondern sicherzustellen, dass die zu verarbeitenden Daten (Du nennst sie „HTML-String/Code-Fragment“) das System selbst nicht stören oder gar gefährden. Optische Effekte für Seitenbesucher und deren Wahrnehmung ist nicht das Problem, für das Sanitizer entwickelt werden.

Sollte man dann deshalb gleich die ganzen Inline-Style aus dem HTHML-Code aus dritter Quelle entfernen?

Hier ist wieder das oben von mir eingeforderte Szenario wichtig, um eine sinnvolle Debatte führen zu können.

Gibt es hierzu irgendwo Erläuterungen, die das Problem verständlich skizzieren?

Das Problem ist nicht klar, weil Du so allgemein formulierst, dass zumindest ich Dir so nicht helfen kann.

Liebe Grüße

Felix Riesterer

[Julius]

Hallo Michael,

eine CSP dient dazu, dass der Server dem Browser mitteilen kann, aus welchen Quellen die ausgelieferte Website „Content“ (CSS, Scripte, Fonts, Bilder etc.) beziehen können soll. Im Normalfall erlaubt die CSP einer Website auch nur die Quellen, die sie wirklich braucht.

Dies dient als zusätzliche Sicherheitsebene, falls die Logik der Website Fehler aufweist.

Sanitizer können aber nicht davor schützen, dass Inline-Styles böswillig den Nutzer optisch täuschen oder etwas vorgaukeln.

Falls man mittels eines Sanitizers HTML-Input säubert, will man üblichweise jegliches JavaScript und CSS herausfiltern und evtl. auch nur eine bestimmte Auswahl an HTML-Elementen und Attributen zulassen.

Eine CSP kann und sollte hier als zusätzliche Sicherheitsebene zum Einsatz kommen.

Gibt es hierzu irgendwo Erläuterungen, die das Problem verständlich skizzieren? Gibt es ggfs. auch eine Web-Seite, die veranschaulicht, wie sich die unterschiedlichen CSP setting für style-src auf die Darstellung auswirken?

Im Grunde ist es ganz einfach: Wenn man Inline-Styles verwendet, diese aber von der CSP verboten werden, werden sie schlicht ignoriert (außer bei einer Report-Only-CSP).

Mir ist das Thema Inline-Styles und die Problematik bekannt, aber ich würde gern dazu eine Demo geben. (... ich könnte natürlich auch am eigenen Server so etwas basteln, aber das kostet zuviel Zeit).

Falls du PHP zur Verfügung hast, kannst du dir in 2 Minuten so etwas basteln:

<?php
header('Content-Security-Policy: …');
?><!doctype html>
<!-- HTML mit Inline-Styles deiner Wahl -->

Will man eine produktiv betriebene Website auf die Auswirkungen einer CSP untersuchen, würde ich diese dort als Report-Only setzen und dann einen Reporting-Dienst (z. B. uriports.com – Die Reports kann man zwar auch selbst einsammeln und aufbereiten, aber das sehe ich nicht als sinnvoll an.) zur Auswertung verwenden. Basierend auf den Resultaten kann man dann ggf. CSP und / oder Website anpassen und die CSP dann scharf schalten, wenn eine gewisse Zeit lang keine Reports eingingen.

Ich kann auch die anderen von uriports unterstützten Reporting-Möglichkeiten nur empfehlen: Mit denen findet man häufig noch andere Probleme, mit denen man gar nicht gerechnet hat...

Viele Grüße
Julius

[Hörnchen]

Hallo Michael,

das was du geschrieben hast ist tatsächlich ein Sicherheitsproblem. Es gibt verschiedene Angriffsszenarien. Eine davon wäre Clickjacking-Methode. Eine weitere Methode ist die Manipulation des Layouts, so das Warnhinweise oder Sicherheitshinweise nicht mehr eingesehen werden können.

Schützt CLP davor? CSP style-src 'unsafe-inline' verhindern Inline-Styles nicht. Das muss man anders lösen.

Viele Grüße

Hörnchen

[Raketenwilli]

Gibt es hierzu irgendwo Erläuterungen, die das Problem verständlich skizzieren?

Ja. Und ich habe die die Empfehlungen mal „durchgezogen“, obwohl es für diese Seite nicht notwendig ist (kein User-generierter Inhalt):

https://developer.mozilla.org/en-US/observatory/analyze?host=code.fastix.org#csp

Dort steht auch, Weshalb welche Einstellung was weshalb wie wirkt.

(Ich hab [A+] geschafft, das Online-Banking einer deutschen Bank kommt übrigens nur auf [B])

Gibt es ggfs. auch eine Web-Seite, die veranschaulicht, wie sich die unterschiedlichen CSP setting für style-src auf die Darstellung auswirken?

Ganz einfach: Wenn es „verboten“ wird ignoriert der Browser das. Und was sich wie ändert hängt also von der Webseite ab. Das Inline-Zeug ist dann weg.

Eigentlich soll das gefährliche Zeug aus dem User- oder Dritt-Content schon von Server weggefiltert werden, aber die Browserhersteller haben da - völlig zu Recht (siehe unten) - offensichtlich kein Vertrauen.

Das ist also nur eine letzte, sehr schwache Verteidigungsline. Aber wenn jede Bank vermeint auf ihrem Webautritt einen Chat haben zu müssen (in den man „bunt“ schreiben und Smileys einfügen kann) kann keine(r) mehr sagen, welche Libarys (Server- und Cklientseitig) da welche Libarys benutzen und wie „sicher“ das ganze Zeug dann noch sein kann, muss diese letzte, sehr schwache Verteidigungsline sein.