man bedim len?

Gerade eben vollzog ich meinen zweiten Sicherheitstest für eine WebMail-Oberfläche innerhalb weniger Monate.
Die Oberflächen kommen von 2 verschiedenen Herrstellern, die auch in Konkurrenz zueinander stehen.
(Schutzzeiten und Absprachen verhinden, daß ich derzeit Details nennen kann, welche Software-Lösungen es sind und von welchen Firmen diese kommen.)

Bemerkenswert und traurig ist, jedoch, daß in beiden Fällen die Art der Sicherheitslöcher annäherend gleich sind:



Zwar werden richtig alle HTML-Anweisungen für
die syntaktisch korrekte Einbindung von JavaScript erkannt und durch Ersetzungen deaktiviert;
Leider ist es jedoch so, daß meist nur syntaktisch korrekte Anweisungengesucht und deaktiviert werden.

Syntaktisch falsche Anweisungen werden nicht gefunden.
Der Internet Explorer hat jedoch das vermeintliche Feature, daß es fehlerhaften HTML-Code zu reparieren versucht.

Konkretes Beispiel:
Eine HTML-Mail mit dem Inhalt

<img src="javascript:document.location=""http://boese-phisching-domain"'>

wird bei einem der WebMail-Oberflächen umgewandelt in

<img src="java-SORRY:document.location="http://boese-phisching-domain"'>


Somit passiert dann nichts.
Wenn der Code jedoch so aussieht:


<img src="javas
cript:document.location="http://boese-phisching-domain"'>


Dann erkennen beide Oberflächen es nicht und das JavaScript wird vom IE, der dies dann netterweise korrigiert, ausgeführt. (Andere Browser machen diesen Unsinn nicht).

Eine automatsiche Umleitung auf eine fremde Site ohne zutun des Benutzers und überdies in einen durch den WebMailer selbst aufgepoppten Fenster ohne URL-Anzeige ist jedoch der ideale Ansatzpunkt für Phishing-Attacken:

Ein Hacker könnte die aktuelle Oberfläche auf seinem Server nachbilden und mittels JavaScript-Anweisungen (die er auf seinen Server dann nicht mehr einschränken lassen müsste) dann das echte parent-window deaktivieren. Der Benutzer würde dann aufgefordert werden, sich nochmal einzuloggen -vermeintlich vielleicht wegen einer zusätzlichen Sicherheitsabfrage oder so- und schon hätte man die Zugangsdaten.


Ebenfalls oft nicht erkennt wird eine syntaktisch fehlerhafte Anweisung der Form:

   <sc
ript>

</scr
ipt>

Auch hier sorgt der nette IE dafür, daß der Code ausgeführt wird.

Was soll man als Fazit sagen?
Zwei Dinge:

• Das vermeintliche Feature des IE, fehlerhaften HTML-Code zu korrigieren, kann leicht durch Hacker ausgenutzt werden, um Code-Injections auf ansonsten geschützen Online-Diensten durchzuführen. Ohne das Feature würden diese Angriffe nicht funktionieren.
  Es empfiehlt sich daher auch aus diesen Grund auf einen anderen Browser umzusteigen.
• Viele Herrsteller von WebMail-Oberflächen, aber auch von anderen Online-Tools mit der Möglichkeit, Ausgaben als HTML bereitzustellen, testen oft nur auf syntaktische Korrektheit. Die üblichen Tricks mit den Einbau von Zeilenumbrüchen innerhalb von HTML-Anweisungen werden oft genauso übersehen wie die Ersetzung von Buchstaben durch Codes anderer Charsets.

Ich fürchte zudem, daß viele Hersteller eher bockig oder zögerlich auf solche Bugmeldungen reagieren. Wer hat denn nun Schuld? Wer muss Mehrarbeit und damit Geld investieren um die Sicherheitslöcher zu beseitigen.
Ein Entwickler einer WebMail-Oberfläche könnte sagen, daß es die Schuld des IE ist und er also nicht verantwortlich gemacht werden kann, wenn ein Browser den Code "seltsam" interpretiert.
Der Browserhersteller würde jedoch sagen, der Anbieter der Lösung ist schuld, ist doch der Browser weitverbreitet und es Sache des Portals oder der Oberfläche ist, dafür zu sorgen, daß keine unliebsamen Codes verbreitet werden.


Nun ja.
Schaun ma mal was wird.

Sobald ich darf, also die übliche Schonzeit nach der Herstellerbenachrichtigung abgelaufen ist und sobald eine englische Übersetzung meiner detailanalyse fertig ist, mach ich ggf. ein BugTraq-Eintrag.