JavaScript blockieren

[MM]

Hallo zusammen,

ich möchte auf meiner Webseite E-Mails anzeigen. Um es nicht ewig zu erklären, was ich machen will, sagen wir einfach mal, dass ich einen Webmailer programmiere.

Nun zeige ich HTML-Mails einfach in einem iframe an. Dies ist leicht umzusetzen, öffnet aber Tür und Tor für Cross-Site-Skripting. Ich würde also gerne das JavaScript der Mail deaktivieren/blockieren/filtern oder zumindest verhindern, dass es aus dem iframe ausbrechen kann.

Auf der Suche nach einem iframe-Attribut, dass den Inhalt quasi einsperrt, habe ich nichts gefunden.

Nun befürchte ich, dass ich mit PHP den Quellcode erst filtern muss. Da bin ich skeptisch, ob man das mit regulären Ausdrücken zuverlässig hinbekommt.

Kennt sich jemand damit aus und hat einen Tipp? Vielleicht PHP-Code, den ich nutzen kann oder eine JavaScript-Bibliothek oder sonst einen Trick?

Vielen Dank!

[suit]

Nun befürchte ich, dass ich mit PHP den Quellcode erst filtern muss.

Ja, das ist so sicher wie das Amen im Gebet.

Da bin ich skeptisch, ob man das mit regulären Ausdrücken zuverlässig hinbekommt.

Die harte Wahrheit:
Zuverlässig wirst du das nie hinbekommen - es gibt vermutlich so viel Browser-Bugs und Fehlerkorrekturroutinen, die du mit einem Regulären ausdruck nicht abfängst - angefangen von simplen Dingen wie falsche Syntax bishin zu gefinkelten Dingen wo z.B. die Tags absichtlich Tippfehler enthalten, damit sie durch solche Routinen nicht ausgefiltert werden aber grade noch durch die Fehlerkorrektur des Browsers kommen.

Kennt sich jemand damit aus und hat einen Tipp?

Zum bereinigen/parsen von HTML oder XHTML würde ich prinzipiell einen HTML/DOM- oder XML-Parser verwenden, die bieten aber dieselben Nachteile wie bereits genannt - wenn du mit einem XML-Parser alle script-Elemente entfernst, erwischt du noch lange nicht alle scirpt-Elemente.

Vielleicht PHP-Code, den ich nutzen kann oder eine JavaScript-Bibliothek oder sonst einen Trick?

Mir ist nichts bekannt.

[Felix Riesterer]

Lieber suit,

Die harte Wahrheit:

Du kannst ja den "HTML-Code" tatsächlich parsen, um dann vom Ergebnis des Parsens wieder einen standardmäßigen Code zu erzeugen, der dann anstelle des originalen HTML-Codes in den Frame ausgegeben wird. Und da hast Du die volle Kontrolle darüber, welche vom Parser erkannten Elemente Du in diese Ausgabe lässt, und welche Du verhinderst.

Das wäre zwar soetwas wie "vor-rendern", aber aus Sicherheitsaspekten wäre das ein Denkansatz, der tatsächlich Sicherheit verspechen und halten kann.

Liebe Grüße,

Felix Riesterer.

[suit]

Das wäre zwar soetwas wie "vor-rendern", aber aus Sicherheitsaspekten wäre das ein Denkansatz, der tatsächlich Sicherheit verspechen und halten kann.

Dazu müsste man ihn aber im Browser des Clients "vor-rendern" - oder zumindst in gängigen Clients.

[MM]

Vielen Dank schon mal für die Antworten. Mein Zwischenstand ist zur Zeit der hier:

  
    public function getSecureHtmlMessage() {  
        $html = $this->html_message;  
  
        $doc = new DOMDocument();  
        $doc->loadHTML(utf8_decode($html));  
        foreach ($doc->getElementsByTagName('script') as $script) {  
            $script->parentNode->removeChild($script);  
        }  
  
        return $doc->saveXML();  
    }  

Damit bekomme ich schon mal die scripts raus. Jetzt kommen noch die ganzen Event-Handler dran. Damit sollte ich das Maß an Sicherheit bekommen, das für meinen Anwendungsfall nötig ist. Es wundert mich bloß, dass ich dafür noch keine fertige PHP-Bibliothek gefunden habe.

[suit]

Damit bekomme ich schon mal die scripts raus. Jetzt kommen noch die ganzen Event-Handler dran. Damit sollte ich das Maß an Sicherheit bekommen, das für meinen Anwendungsfall nötig ist. Es wundert mich bloß, dass ich dafür noch keine fertige PHP-Bibliothek gefunden habe.

Wenn es in jeder Programmiersprache für jeden 5-Zeilen-Codeschnipsel eine Bibliothek gäbe, hätten wir ein ernsthafes Problem mit der Dimension der Codebasis.

[MM]

Wenn es in jeder Programmiersprache für jeden 5-Zeilen-Codeschnipsel eine Bibliothek gäbe, hätten wir ein ernsthafes Problem mit der Dimension der Codebasis.

Stimmt! Aber das komplizierte kommt ja noch. Die Event-Handler werden deutlich mehr Arbeit. Und da ich mir nicht vorstellen kann, dass ich weltweit der erste Entwickler bin, der vor diesem Problem steht, hatte ich auf fertigen Code gehofft.

[suit]

Stimmt! Aber das komplizierte kommt ja noch. Die Event-Handler werden deutlich mehr Arbeit.

Wieso? Anstatt einem Element entfernst du halt ein Attribut - die Liste der möglichen Eventhandler ist begrenzt und bekannt. Ich sehe da jetzt nicht das Problem.

[Kai345]

[latex]Mae  govannen![/latex]

Stimmt! Aber das komplizierte kommt ja noch. Die Event-Handler werden deutlich mehr Arbeit.

Wieso? Anstatt einem Element entfernst du halt ein Attribut - die Liste der möglichen Eventhandler ist begrenzt und bekannt.

Man möchte in diesem Fall alle Attribute, die mit „on“ beginnen ausfiltern, statt die Attribute einzeln anhand einer Liste auszuschließen, Dies würde nämlich bedeuten, daß man sich ständig über neu hinzukommende Eventhandler-Attribute informieren müßte.

Reicht das oder habe ich was übersehen?

Schleife über Attribute
  Wenn (Attributname mit „on“ beginnt) oder (Attributwert „javascript:“ enthält)
    entferne Attribut
  ende Wenn
ende Schleife

Stur lächeln und winken, Männer!
Kai

[MM]

» Schleife über Attribute

Wenn (Attributname mit „on“ beginnt) oder (Attributwert „javascript:“ enthält)
    entferne Attribut
  ende Wenn
ende Schleife

Ja genau so mache ich es jetzt (bzw. versuche es; es hängt noch irgendwo). Allerdings habe ich mich für die komplette onXXX-Liste entschieden.

[Kai345]

[latex]Mae  govannen![/latex]

Ja genau so mache ich es jetzt (bzw. versuche es; es hängt noch irgendwo). Allerdings habe ich mich für die komplette onXXX-Liste entschieden.

Genau da liegt das Problem: Es gibt keine komplette Liste. Du müßtest also sehr regelmäßig alle Herstellerseiten abklappern (wegen Hersteller-/Gerätespezifischer Handler), die Standards beobachten etc. und diese Liste ständig aktualisieren. Beispielweise: sind all diese Handler in deiner Liste? Und das sind nur die allgemeinen  mozilla. Microsft hat sicher eigene, Webkit vllt auch, usw.

Stur lächeln und winken, Männer!
Kai

[zehbaeh]

Die Event-Handler werden deutlich mehr Arbeit. Und da ich mir nicht vorstellen kann, dass ich weltweit der erste Entwickler bin, der vor diesem Problem steht, hatte ich auf fertigen Code gehofft.

Zum Filtern von HTML macht IMHO eine "Whitelist" deutlich mehr Sinn/Sicherheit.

[suit]

Zum Filtern von HTML macht IMHO eine "Whitelist" deutlich mehr Sinn/Sicherheit.

Wenn man Script-Elemente und Eventhandler-Attribute entfernen will, macht eine Blacklist deutlich mehr Sinn. Sämtliche anderen Elemente und Attribute sind deutlich in der Überzahl.

[zehbaeh]

Zum Filtern von HTML macht IMHO eine "Whitelist" deutlich mehr Sinn/Sicherheit.

Wenn man Script-Elemente und Eventhandler-Attribute entfernen will, macht eine Blacklist deutlich mehr Sinn. Sämtliche anderen Elemente und Attribute sind deutlich in der Überzahl.

Das macht mehr Arbeit, mehr Sinn aber IMHO nicht.
Zukünftige Elemente/Attribute kannst Du mit einer Blacklist nicht erfassen.

[suit]

Das macht mehr Arbeit, mehr Sinn aber IMHO nicht.

Elemente: script
Attribute: onabort,onblur,onchange,onclick,ondblclick,onerror,onfocus,onkeydown,onkeypress,onkeyup,onload,onmousedown,onmousemove,onmouseout,onmouseover,onmouseup,onreset,onselect,onsubmit,ontouchend,ontouchmove,ontouchstart,onunload

Macht in Summe 1 Element und 23 Attribute - jetzt bis du dran, mir deine Whitelist zu zeigen. Ich geh' jetzt mal geschätzt von 100 bis 150 Einträgen aus.

Zukünftige Elemente/Attribute kannst Du mit einer Blacklist nicht erfassen.

Und in eine Whiteliste werden sie magischerweise von selbst eingefügt?

[suit]

Elemente: script
Attribute: onabort,onblur,onchange,onclick,ondblclick,onerror,onfocus,onkeydown,onkeypress,onkeyup,onload,onmousedown,onmousemove,onmouseout,onmouseover,onmouseup,onreset,onselect,onsubmit,ontouchend,ontouchmove,ontouchstart,onunload

Die Liste ist selbstverständlich unvollständig und lässt sich mit Kais Vorschlag verbessern - aber das ist ohnehin ein Projekt, welches Wartung benötigt.

[Kai345]

[latex]Mae  govannen![/latex]

Elemente: script
Attribute: onabort,onblur,onchange,onclick,ondblclick,onerror,onfocus,onkeydown,onkeypress,onkeyup,onload,onmousedown,onmousemove,onmouseout,onmouseover,onmouseup,onreset,onselect,onsubmit,ontouchend,ontouchmove,ontouchstart,onunload

Die Liste ist selbstverständlich unvollständig

Geringfügig ;) Alleine anhand der von mir verlinkten MDN-Eventhandlerliste gibt es bereits 75 (wimnvh) potentielle onXXX Attribute (die sicherlich nicht alle sinnvoll sind), dennoch ein „kleiner“ Unterschied zu deinen 23 :) Mit den vendor-Handlern und der Arbeit wärst du dann auch nicht besser dran als mit einer von dir wegen zu großem Aufwand abgelehnten Whitelist.

Stur lächeln und winken, Männer!
Kai

[zehbaeh]

Zukünftige Elemente/Attribute kannst Du mit einer Blacklist nicht erfassen.

Und in eine Whiteliste werden sie magischerweise von selbst eingefügt?

Natürlich nicht, die werden bei Bedarf (der ggf. gar nicht besteht) hinzufgefügt. Während dessen ist die Anzeige/Ausgabe vielleicht unvollständig aber sicher.
Mit deiner Blacklist hast Du bis zur Anpassung ggf. eine Sicherheitslücke.

[suit]

Natürlich nicht, die werden bei Bedarf (der ggf. gar nicht besteht) hinzufgefügt. Während dessen ist die Anzeige/Ausgabe vielleicht unvollständig aber sicher.
Mit deiner Blacklist hast Du bis zur Anpassung ggf. eine Sicherheitslücke.

Das lass' ich als Argument gelten - wobei die Frage zu stellen ist, inwieweit ein Webmail Client für die Sicherheit in diesem Belangen verantwortlich ist, wenn eigentlich der Browser das Problem ist.

[zehbaeh]

Natürlich nicht, die werden bei Bedarf (der ggf. gar nicht besteht) hinzufgefügt. Während dessen ist die Anzeige/Ausgabe vielleicht unvollständig aber sicher.
Mit deiner Blacklist hast Du bis zur Anpassung ggf. eine Sicherheitslücke.

Das lass' ich als Argument gelten - wobei die Frage zu stellen ist, inwieweit ein Webmail Client für die Sicherheit in diesem Belangen verantwortlich ist, wenn eigentlich der Browser das Problem ist.

Ich plädiere für den Browser auf Unschuldig. Der macht halt das was von ihm verlangt wird, sofern er es denn kann -- oder glaubt zu können (da wären Vorwürfe eher angebracht.)

[Der Martin]

Hallo,

Mit deiner Blacklist hast Du bis zur Anpassung ggf. eine Sicherheitslücke.
Das lass' ich als Argument gelten - wobei die Frage zu stellen ist, inwieweit ein Webmail Client für die Sicherheit in diesem Belangen verantwortlich ist, wenn eigentlich der Browser das Problem ist.

wenn du so argumentierst, darfst du auch Benutzereingaben ungefiltert mit echo wieder an den Client ausgeben - wenn dadurch was schiefgeht, trifft's den Client. Selber schuld, wenn er nicht für seine eigene Sicherheit sorgen kann. ;-)

Ciao,
 Martin

[Sven Rautenberg]

Moin!

Elemente: script
Attribute: onabort,onblur,onchange,onclick,ondblclick,onerror,onfocus,onkeydown,onkeypress,onkeyup,onload,onmousedown,onmousemove,onmouseout,onmouseover,onmouseup,onreset,onselect,onsubmit,ontouchend,ontouchmove,ontouchstart,onunload

Element: style
Attribut: style

Ja, in CSS kann man Javascript verpacken! Macht zwar nur in wenigen Browsern aktiv Sinn (namentlich: IE), aber IEs gibts doch noch genug.

- Sven Rautenberg

[MudGuard]

Hi,

Elemente: script
Attribute: onabort,onblur,onchange,onclick,ondblclick,onerror,onfocus,onkeydown,onkeypress,onkeyup,onload,onmousedown,onmousemove,onmouseout,onmouseover,onmouseup,onreset,onselect,onsubmit,ontouchend,ontouchmove,ontouchstart,onunload
Element: style
Attribut: style

die link-Elemente mit stylesheets sind dann auch noch betroffen.

Ja, in CSS kann man Javascript verpacken! Macht zwar nur in wenigen Browsern aktiv Sinn (namentlich: IE), aber IEs gibts doch noch genug.

schrieb ich ja schon vor Stunden

cu,
Andreas

[suit]

Elemente: script
Attribute: onabort,onblur,onchange,onclick,ondblclick,onerror,onfocus,onkeydown,onkeypress,onkeyup,onload,onmousedown,onmousemove,onmouseout,onmouseover,onmouseup,onreset,onselect,onsubmit,ontouchend,ontouchmove,ontouchstart,onunload

Element: style
Attribut: style

Ja, in CSS kann man Javascript verpacken! Macht zwar nur in wenigen Browsern aktiv Sinn (namentlich: IE), aber IEs gibts doch noch genug.

Das liebe ich an diesem Forum: es kommt immer jemand dazu, der es noch besser weiß :) was dann dazu führt, dass man die theoretischen Grundlagen für ein Monster hat, dass keiner mehr sinnvoll umsetzen kann :D

[Sven Rautenberg]

Moin!

Das liebe ich an diesem Forum: es kommt immer jemand dazu, der es noch besser weiß :) was dann dazu führt, dass man die theoretischen Grundlagen für ein Monster hat, dass keiner mehr sinnvoll umsetzen kann :D

Der Punkt ist: Dein Vorschlag ist Mist gewesen. Man kann keine Blacklist pflegen, in die man alles bekannt Böse einträgt. Man kann lediglich eine Whitelist pflegen, in die man alles bekannt Unschädliche einträgt.

- Sven Rautenberg

[dedlfix]

Tach!

Man kann keine Blacklist pflegen, in die man alles bekannt Böse einträgt. Man kann lediglich eine Whitelist pflegen, in die man alles bekannt Unschädliche einträgt.

Um dann festzustellen, dass das unschädlich geglaubte Element, Attribut oder auch Dateiformat plötzlich schädliche Inhalte transportieren kann, weil irgendwo eine bisher unbekannte Sicherheitslücke klafft.

dedlfix.

[suit]

Das liebe ich an diesem Forum: es kommt immer jemand dazu, der es noch besser weiß :) was dann dazu führt, dass man die theoretischen Grundlagen für ein Monster hat, dass keiner mehr sinnvoll umsetzen kann :D

Der Punkt ist: Dein Vorschlag ist Mist gewesen.

Ja - und das ist gut so, dass das ausdiskutiert wurde und durch die Vielzahl der Mitleser und -schreiber ein letzlich doch ordentliches Ergebnis rauskam.

Man kann keine Blacklist pflegen, in die man alles bekannt Böse einträgt. Man kann lediglich eine Whitelist pflegen, in die man alles bekannt Unschädliche einträgt.

Es gibt sicher einige Beispiele, bei denen unschädigle Dinge plötzlich schädlich werden, weil irgend ein Feature dazukommt :) ein modernes Beispiel ist z.B. History Stealing.

[dedlfix]

Tach!

Und da ich mir nicht vorstellen kann, dass ich weltweit der erste Entwickler bin, der vor diesem Problem steht, hatte ich auf fertigen Code gehofft.

Bist du auch nicht. Ich erinnere mich an einen Bericht über eine ausgenutzte Sicherheitslücke bei einem namhaften Projekt, das bei einem ähnlichen Filterversuch ein paar Möglichkeiten übersehen hatte. Und es dauert keine Minute, bis man beim Suchen nach "php filter javascript" auf Hinweise zu zumindest einem Filter-Projekt stößt (HTML Purifier).

dedlfix.

[MudGuard]

Hi,

Wenn es in jeder Programmiersprache für jeden 5-Zeilen-Codeschnipsel eine Bibliothek gäbe, hätten wir ein ernsthafes Problem mit der Dimension der Codebasis.

Stimmt! Aber das komplizierte kommt ja noch. Die Event-Handler werden deutlich mehr Arbeit. Und da ich mir nicht vorstellen kann, dass ich weltweit der erste Entwickler bin, der vor diesem Problem steht, hatte ich auf fertigen Code gehofft.

Javascript kann sich auch an anderen Stellen verstecken, z.B. in CSS (z.B. im IE: expression() oder per behaviour Eigenschaft.)

Und IIRC war das doch auch bei alten IE-Versionen so, daß bei einem <img src="http://example.org/script.js"> das ausgelieferte Javascript an den JS-Interpreter übergeben wurde ...

cu,
Andreas

[suit]

Und IIRC war das doch auch bei alten IE-Versionen so, daß bei einem <img src="http://example.org/script.js"> das ausgelieferte Javascript an den JS-Interpreter übergeben wurde ...

Thunderbird und Firefox ließen sich mit einem manipulierten PNG ins jenseits schicken:
http://www.mozilla.org/security/announce/2010/mfsa2010-41.html

Ich verweise daher nochmal hierauf:
https://forum.selfhtml.org/?t=209247&m=1423986