Es sollte im Interesse eines jeden Nutzer des Internets sein, einen möglichst sicheren Browser zu benutzen. Einem Experten-Team ist nun jedoch gelungen, die offensichtlich wirkliche Bedrohung ausfindig zu machen, bei der auch der sicherste Browser machtlos scheint. Kein Upgrade und kein Hotfix sind gegen die Tücken manipulierter Webformulare gefeit. Das Problem ist seit über sechs Jahren bekannt, doch scheint dies kein Entwickler-Team wirklich brennend zu interessieren.

Eigentlich möchte man es gar nicht glauben, dass das Ausfüllen eines Formulars über das Internet eine solch große Gefahr darstellen soll. Schließlich handelt es sich dabei um etwas schon fast Alltägliches und Vertrautes. Einer Gruppe von Wissenschaftlern ist nun jedoch gelungen, die wahren Risiken des Web zu offenbaren.

weiterlesen

a_d_s

Wie genau unterscheidet sich der "gefährliche Content" eines x-beliebigen Servers auf Port 9368 von dem auf Port 80, wenn in beiden Fällen ein Angreifer die Webseite kontrolliert?

Sonnentier

Das ist mir auch nicht ganz klar.
Wenn der Server kompromittiert ist, kann man doch sowieso alles sehen?

a_d_s

Es geht wohl eher darum, dass ein x-beliebiger Serverdienst dem Browser etwas gefährliches unterschieben könne - und dieser Server könnte auf einem anderen als dem Standardport laufen. Darum werden diverse Ports auch geblockt.

Nur arbeitet das völlig am Sinn vorbei: ein schädlicher Server kann auch auf dem Port des Webservers Daten versenden.

pvna

Habe ich das jetzt richtig verstanden,
dass in der Fehlermeldung, die der Server ggf. an den Browser schickt, Schadcode enthalten sein kann, den der Browser nicht bloß anzeigt, sondern ausführen könnte?

Und (warum) trifft das nur bei Web-Formularen zu?

a_d_s

Aus genau dem Grund stelle ich mir die Frage, welchen Sinn dieser Newsbeitrag überhaupt hat ...

XphX

Seht es positiv. Wenigstens hat das mit der Rechtschreibung geklappt

Der Sinn des Artikels leuchtet mir dennoch nicht ganz ein, ich les mir das morgen nochmal durch.

//edit: das Ganze ist für mich auch nach einem ausgiebigen Frühstück undurchschaubar. Also erstmal nichts bei Webformularen und vorallem nicht bei Google eingeben!!!!

Hollii

Irgendwie fehlt da doch noch was... Ich hab schon ein 2.tes "weiterlesen" unter dem "weiterlesen" gesucht, weil ich dachte, es geht noch weiter..

ADI64

Was haben jetzt kompromittierte non-HTML-Seiten mit Webformularen zu tun?
ist für mich irgendwie nicht wirklich aus dem Bericht hervorgegangen

re-aktor

Ich versteh nur Bahnhof - obwohl ich in der Materie firm bin. Im Artikel wird nichts klar...

Einer der schlechtesten Blog Artikel im Gulli seit lamgem!

maX7C

Webformulare? Ports? Nicht Http-Server?

Der zusammenhang bleibt mir leider verborgen.

aNtiCHrist

Ich musste auch erst die eigentliche Quelle lesen, bis ich die Problematik verstanden habe: Wenn man einem nicht-HTTP-Server die Formulardaten übermittelt und diese z. B. ein <script>alert('Peng')</script> enthalten, könnte es sein, dass der so etwas wie Command <script>alert('Peng')</script> unknown. antwortet. Wenn der Browser die Antwort nun als HTML interpretiert, hat man eine XSS-Schwachstelle über die man z. B. die Cookies auslesen kann. Ich dachte zwar, dass Cookies portgebunden wären, aber das ist offenbar nicht der Fall.

Dass die Ports blockiert werden, kannte ich bisher nur als Gegennmaßnahme für das umgekehrte Szenario: Man kann mit einem Formular unter Umständen Daten auf einem Server modifizieren, der einen ganz anderen Dienst als HTTP anbietet. Siehe http://www.mozilla.org/projects/netlib/PortBanning.html

Noch ein Tipp für den Autor des Artikels: http://de.wikipedia.org/wiki/Plenk

a_d_s

Was unterscheidet die "unknown" Antwort samt vorherigem Inhalt von der Rückgabe eines beliebigen anderen Inhaltes? Beides kann für die Darstellung gefährlich werden.

Zu den Ports: irgendjemand muss den Browser auf diesen Port gelenkt haben, ob mit Absicht (Virus ect.) oder nicht (Programmierfehler). Sowohl Browser wie Server müssen jedoch mit diesem Problem umgehen können: irgendein realer Angreifer könnte sonst z.B. den Server dadurch in Verlegenheit bringen, indem er mal wirklich ungewöhnliche Anfragen sendet.

Ich sehe die Problematik, aber ich sehe kein Problem, das anderswo nicht auch existiert.

aNtiCHrist

Was meinst du mit anderswo? Wenn Webserver (durch ein Script oder eine unüberlegte Fehlermeldung) einfach die Formulardaten innerhalb eines HTML-Dokuments wieder ausgibt, ist das eine XSS-Schwachstelle, ganz klar. Die Problematik sollte aber eigentlich jedem Webanwendungsentwickler bekannt sein und die Entwickler der Webserver sollten erst recht von der Gefahr wissen. Die Abhilfe ist jedenfalls einfach, man schreibt alle Zeichen mit einer speziellen Bedeutung in HTML als Zeichenreferenz.

Wenn z. B. ein SMTP-Server sich so verhält, ist der Fall aber nicht mehr so klar, denn hier wird ja normalerweise kein HTML verarbeitet und man hat sich offenbar bisher nicht groß Gedanken um das Problem gemacht. Dementsprechend groß ist das Potenzial hinter dieser Technik. Zeichenreferenzen sind hier zudem keine Lösung. Man müsste die Browser dazu bringen, fehlerhafte Antworten nicht mehr als HTML zu interpretieren, aber hier stellt sich das Problem, wie streng man die Grenzen in der Praxis ziehen kann, ohne dass fehlerhafte HTTP-Header gleich dazu führen, dass der Browser aussteigt. Auch ist es denkbar, dass man von einem nicht-HTTP-Dienst durchaus eine korrekte HTTP-Antwort erhalten könnte, etwa über einen unsinnigerweise laufenden Echo-Dienst auf Port 7, den der IE nicht filtert.

a_d_s

Zitat:

Zitat von aNtiCHrist

Was meinst du mit anderswo? Wenn Webserver (durch ein Script oder eine unüberlegte Fehlermeldung) einfach die Formulardaten innerhalb eines HTML-Dokuments wieder ausgibt, ist das eine XSS-Schwachstelle, ganz klar.

Die Schwachstelle bzw. das unsinnige Verhalten liegt aber auf der Serverseite.
Der Browser schickt eine Anfrage und bekommt eine Antwort - woher soll er wissen, dass er seine eigene Anfrage zurück bekommt?

Inwieweit sich der Browser nun dadurch Schadcode oder Probleme unterschieben lässt, ist eine andere Baustelle und hat mit dem beschriebenen Problem nichts zu tun. Eine infiltrierte Webseite könnte ebenfalls Schadcode verschicken und der Browser darf nicht drauf reinfallen.

aNtiCHrist

Zitat:

woher soll er wissen, dass er seine eigene Anfrage zurück bekommt?

Das kann er nicht wissen, aber das ist auch völlig egal. Das Problem ist, dass er eben Antworten bekommt, die er nicht als HTTP-Antwort mit HTML im Body auffassen sollte aber dann genau das tut.

Ein unsinniges Verhalten kann ich auf der Serverseite nicht erkennen, wenn der Fehler konkret benennt und dazu den fehlerhaften Befehl wiederholt. Selbst wenn man das abstellen würde: Man könnte z. B. ja bei einem Freemailer ein Konto anlegen, dorthin eine Mail mit XSS-Code schicken und dann das Opfer über ein Formular (mit den nötigen Logindaten) scriptgesteuert per POP3 dort einloggen und die Mail abrufen lassen. Da steckt dann die gesendeten Daten nicht mal der Schadcode drin.

Die einzigen Auswege die ich in diesen Fällen sehe sind Verbindungsabbrüche bei Protokollfehlern (wie oben gezeigt nicht immer ausreichend), die Bindung von Cookies an spezifische Hostnamen/Ports oder aber die strikte Filterung von Well-Known-Ports in Kombination mit einer Nutzung ausschließlich dieser Ports für Dienste, sofern innerhalb der Domain ein Webserver mit Cookie-Nutzung betrieben wird. Im schlimmsten Fall kann man halt (von fremden Sites initiierte) HTTP-Verbindungen nur noch auf Port 80 zulassen und müsste sonst zumindest eine Warnung anzeigen lassen.

Zitat:

Eine infiltrierte Webseite könnte ebenfalls Schadcode verschicken und der Browser darf nicht drauf reinfallen.

Auf einer bereits infiltrierten Site braucht man kein XSS mehr. Und wie soll denn bitte ein Browser erkennen können, dass an einer Site manipuliert wurde und der Scriptcode zum Ausspähen der Cookie genutzt wird?

MSX

Zitat:

Zitat von aNtiCHrist

Man müsste die Browser dazu bringen, fehlerhafte Antworten nicht mehr als HTML zu interpretieren, aber hier stellt sich das Problem, wie streng man die Grenzen in der Praxis ziehen kann, ohne dass fehlerhafte HTTP-Header gleich dazu führen, dass der Browser aussteigt.

Ich sehe da nur eine absolut strikte Trennung von korrekten Paketen und fehlerhaften als Lösung. Ich meine, wenn ich das richtig sehe, ist das eigentliche Problem ja doch eine Ebene höher.

Warum soll da ein Browser aussteigen? Wenn man sagt, nach beispielsweise 10 Versuchen ist halt Schluß, dann bekommt man eine Fehlermeldung. Oder sehe ich das jetzt falsch?

aNtiCHrist

Zitat:

Ich sehe da nur eine absolut strikte Trennung von korrekten Paketen und fehlerhaften als Lösung.

Klar, das wäre sicherlich wünschenswert. Aber ich will nicht wissen, wie viele Server von sich aus schon kaputt sind oder durch fehlerhafte Konfiguration oder durch Scripte fehlerhafte Headerdaten liefern. Ich zeigte ja außerdem bereits, dass auch ein nicht-HTTP-Server durchaus eine Antwort senden kann, die zugleich eine gültige HTTP-Antwort ist. Da kann man dann so strikt trennen wie man will, die Unterscheidung ist nicht möglich.

Zitat:

Warum soll da ein Browser aussteigen?

Weil er doch nicht einfach so weitermachen sollte. Ein Abbruch (mit entsprechender Meldung) ist immer noch die einfachste Fehlerbehandlung.

Zitat:

Wenn man sagt, nach beispielsweise 10 Versuchen ist halt Schluß, dann bekommt man eine Fehlermeldung. Oder sehe ich das jetzt falsch?

Was denn nun? Oben willst du strikt trennen, hier auf einmal 9 Fehler durchgehen lassen? Der IE sendet offenbar ohne Cookie gerade mal 9 Zeilen in seinen normalen HTTP-Anfragen, da könnte man mit 9 Fehlern also wunderbar auskommen ...

Überhaupt: Wer sollte denn die Fehlermeldung generieren? Woher weiß denn der Browser, dass die Antworten des Servers Fehlermeldungen sind? Er versteht das Protokoll doch gar nicht, er kennt nur die Statuscodes 4xx hinter dem HTTP/x.x als Fehler und es kann ja durchaus Dienste geben, die mit ihren Fehlermeldungen syntaktisch korrekte HTTP-Headerfelder erzeugen. Error: unknown_command wäre auch in einer HTTP-Antwort gültig, unbekannte Feldnamen werden dann einfach verworfen.

Das Problem ist jedenfalls nicht mal eben zu lösen, alle mir einfallenden Lösungen würden sicherlich die eine oder andere Konfiguration unbenutzbar machen, Änderungen an prinzipiell unschuldigen Diensten nötig machen oder aber eben nicht zuverlässig schützen. Mal sehen, was sich die Entwickler da einfallen lassen. Möglicherweise wartet man ja auch ab, bis die Schwachstelle tatsächlich ausgenutzt wird oder die Lösung wird den Betreiber/Entwickler der missbrauchten Dienste überlassen.

antiMahn

Der Verfasser dieses News Artikels, hat ein Thema aufgegriffen das seit Jahren bestens bekannt ist.
Allerdings hat er die Thematik offensichtlich nicht verstanden.

Entgegen der Meinung des Artikelverfassers, sind es keinesfalls die Browser die Unheil anrichten, sondern es sind die Daten die als Formularinhalte (natürlich via Browser) an den Server gesendet werden.

Selbstverständlich stellt der Browser alles dar, was der Server ihm als Response anbietet; es obliegt also dem Server (oder besser: den auf dem Server für die Verarbeitung von Requests zuständigen Programmen) durch geeignete Maßnahmen dafür zu sorgen dass kein schädlicher Code entgegengenommen und ausgeführt wird.

Es wäre grober Unfug, Sicherheitsüberprüfungen ausgerechnet der Clientseite (also dem Browser) zu übertragen.

erc

Zitat:

Zitat von antiMahn

Selbstverständlich stellt der Browser alles dar, was der Server ihm als Response anbietet; es obliegt also dem Server (oder besser: den auf dem Server für die Verarbeitung von Requests zuständigen Programmen) durch geeignete Maßnahmen dafür zu sorgen dass kein schädlicher Code entgegengenommen und ausgeführt wird.

Wieso ist es selbstverständlich, dass ein Browser auf einen HTTP Request, der eine ungültige Antwort erzeugt, dies drotzdem als HTML darstellt? Das ist doch allein ein hausgemachtes Problem der Browser-Entwickler.

Oder anders. Was kann da ein Entwickler eines Dienstes wie FTP, SMTP, POP3 usw dafür das irgendein Client wirres zeug schickt und die standardkonforme Reaktion ein Sicherheitsproblem für den Client darstellt?

antiMahn

Zitat:

Zitat von erc

Wieso ist es selbstverständlich, dass ein Browser auf einen HTTP Request, der eine ungültige Antwort erzeugt, dies drotzdem als HTML darstellt? Das ist doch allein ein hausgemachtes Problem der Browser-Entwickler.

Oder anders. Was kann da ein Entwickler eines Dienstes wie FTP, SMTP, POP3 usw dafür das irgendein Client wirres zeug schickt und die standardkonforme Reaktion ein Sicherheitsproblem für den Client darstellt?

Wenn ein Client (also ein Browser) wirres Zeug an einen Server-Dienst schickt ...
wie sollte dann aus der standardkonformen Reaktion des Server-Dienstes ein Sicherheitsproblem für den Client entstehen?

aNtiCHrist

Habe ich doch oben bereits erklärt: Wenn die Antwort irgendwelche HTML-artigen Komponenten enthält und der Browser das dann fälschlicherweise extrem fehlertolerant als HTML interpretiert.

antiMahn

Zitat:

Zitat von aNtiCHrist

Habe ich doch oben bereits erklärt: Wenn die Antwort irgendwelche HTML-artigen Komponenten enthält und der Browser das dann fälschlicherweise extrem fehlertolerant als HTML interpretiert.

Und was soll das alles mit Formularen zu tun haben die ich selbst ausfülle und an den Server sende?
Und wie sollte daraus dann ein Sicherheitsproblem für den Client entstehen?

aNtiCHrist

Die Formulare füllst du natürlich nicht selbst aus, die werden dir fertig mit dem XSS-Code ausgefüllt von einer bösartigen Seite geliefert und dann per JS auch automatisch abgeschickt. Wenn der Dienst den gelieferten Code nun in irgendeiner Form wiederholt, führt der Browser ihn in dem Sicherheitskontext der Domain des Dienstes aus. Es reicht daher aus, wenn du eine bösartige Seite aufrufst und JS nicht deaktiviert hast.

Das Sicherheitsproblem ist die Ausspähbarkeit von Cookies, die für die Domain des missbrauchten Diensts gesetzt wurden.

Anzeige