“WASC sieht Web 2.0 im Visier der Angreifer” (heise.de)

Mit 19 Prozent aller aufgezeichneten Vorfälle sind Web-2.0-Seiten das bevorzugte Ziel der Cyberkriminellen. Zum einen haben solche Plattformen große Benutzerzahlen, zum anderen lassen die Techniken der Content-Generierung durch Benutzer und das Konzept der dynamischen Webseiten zahlreiche Angriffsmöglichkeiten zu. Signifikant angestiegen sind Cross-Site-Scripting- und Cross-Site-Request-Forgery-Angriffe(…)

In den Kommentaren zum Artikel meinte jemand:

Immerhin 19% von denen ich gar nix mitkrieg. =)

Ich glaube, er weiß gar nicht wie Recht er damit hat.


<einschub>
Bei nicht-persistentem/reflektivem Cross-Site Scripting (de.wikipedia.org) wird der Code über die URL injiziert und hierbei gibt es zwei Methoden wie man die Daten an den Server sendet, GET und POST.

GET-Request
Die Daten werden sichtbar in der Adresszeile an den Server übertragen:
http://domain.tld/suche.script?suchwort=irgendetwas

POST-Request
Nach dem Absenden sieht man in der Adresszeile nur:
http://domain.tld/suche.script


Hier ein kleines Beispiel für XSS, per GET übertragen:

Wie man sieht wurde in die Website etwas eingefügt, sofort erkennbar. Auch sofort erkennbar in der Adresszeile des Browsers, denn der injizierte Code wird auch dort angezeigt,

Und hier, auf der gleichen Website, eine Injektion per POST übertragen:

Auch hier sieht man die Veränderung in der Website, aber hier wird in der Adresszeile nichts angezeigt.

(Den Verlag habe ich bereits vor mehreren Monaten angeschrieben. Dieser Hinweis nur, damit kein falscher Eindruck entsteht.)
</einschub>


Warum liest man nie davon, dass jemand Opfer von XSS oder CSRF wurde und nur sehr selten davon, dass in einer Website entsprechende Lücken geschlossen wurden?

Am häufigsten trifft man auf die nicht-persistente/reflektive Art von XSS. Dabei werden keine Daten direkt am Server gespeichert, es werden also keine bleibenden Veränderungen an einer Website vorgenommen. Ich behaupte mal, dass das der Grund dafür ist, dass sehr viele Unternehmen Cross-Site Scripting nicht als eine echte Lücke ansehen. Erst wenn eine Lücke öffentlich wird, wird auch das Unternehmen (manchmal) aktiv, da es um seinen guten Ruf besorgt ist. Das Schließen einer Lücke kostet Geld. Ist die Lücke unbekannt – was nur bedeutet, bisher hat noch kein Opfer geklagt – meinen die Unternehmen wohl: “Lücke schließen? Rausgeschmissenes Geld!”

Wer Opfer von Cross-Site Scripting oder Cross-Site Request Forgery wurde, der wird evtl. feststellen das über irgendeinen Weg Daten in falsche Hände geraten sind, aber wie man an dem obigen POST-Beispiel sieht, wird er kaum bemerken, auf welcher Website er zum Opfer wurde.


Im Archiv von xssed.com findet man dokumentierte XSS-Lücken. Das Projekt wurde im Februar 2007 gestartet. Lücken vom Projektstart wurden noch immer nicht geschlossen, was wohl das Desinteresse der Websitebetreiber dokumentiert.

Auf meinen letzten Beitrag “Relaunch bundestag.de inkl. alter und neuer Lücken” habe ich heute einen sehr schönen Kommentar erhalten. Vielen Dank dafür an den “Informant”.

Ich hab mal ne Weile bei so einem Dienstleister gearbeitet und kann daher sagen, dass es im Grunde eigentlich immer nur ne Sache des Geldes ist.

Bezahlt wird oft für schnelles arbeiten und ein gutes Aussehen der Seite. Aber wenn es um das Thema Sicherheit geht, wird es zunehmend schwammig und viele Auftraggeber wollen hierfür auch nicht wirklich etwas bezahlen, während sich der Dienstleister die Sicherheit (natürlich) extra bezahlen lassen will… nix auf dieser Welt gibt es kostenlos und schon garnicht Sicherheit!

Dabei stellt sich die Frage, inwieweit sich der Auftraggeber überhaupt in das Thema “Sicherheit in Websites” eingearbeitet hat, dies in seinem Lastenheft spezifiziert oder sich evtl. nur auf den Dienstleister verlässt.

Es gibt sicher Teile/Funktionen einer Website die im Lastenheft nicht explizit aufgeführt sind und von beiden Seiten als gegebener Standard angesehen werden, wie z.B. das eine Website in den am häufigsten verbreiteten Browsern benutzbar sein muss.

Was die Sicherheit angeht, da gibt es auch den einen oder anderen Standard der nicht erwähnt wird. Die Eingabevalidierung gehört aber offensichtlich noch nicht zu den Standards. Ist die Eingabevalidierung etwas was der Dienstleister gesondert in seinem Pflichtenheft aufführen und abrechnen sollte, und was der Auftraggeber einfach aus Kostengründen daraus streichen lassen kann?

Die Seiten gehen dann ohne wirkliche Sicherheit online und es wird vorallem vom Auftraggeber gehofft, dass halt nichts passiert, während der Dienstleister oft über ∼80% der bestehenden Lücken bescheid weiß, aber eben nicht dafür bezahlt wurde diese zu schließen. Auch wenn in Bloggs wie diesem oft der Eindruck erweckt wird, die Entwickler der Dienstleister wären nur Praktikanten mit Hauptschulabschluss und einem Crash-Kurs in PHP/HTML, ist dies oft nicht der Fall. Tatächlich wissen die Entwickler oft sehr genau bescheid. Aber wie heißt es so schön? Ohne Moos nix los.

Wenn die Dienstleister wirklich ∼80% der Lücken kennen, dann müssen sie sich auch darüber im klaren sein, dass ihre Reputation zu Schaden kommt, wenn Lücken öffentlich werden. Auch dieses Risiko muss der Auftraggeber dann in irgendeiner Form bezahlen.

Bundestag.de ist evtl. ein schlechtes Beispiel, da hier verschiedene Dienstleister mitgewirkt haben und ich den Auftraggeber angeschrieben hatte und nicht den jeweiligen Dienstleister. Oftmals habe ich es aber mit den Entwicklern direkt zutun, denen ich erklären muss, dass z.B. XSS nicht nur in dem einen Browser, des einen Users abläuft, dass nach dem Bekanntwerden der Möglichkeit von persistenten Injections, auch systemweit geprüft und bereinigt werden muss, was User bereits in das System eingefügt haben, etc. Bei manchen Entwicklern habe ich wirklich den Eindruck, dass ihnen ein Hacker-Crashkurs dringend fehlt, um zu verstehen was alles möglich ist.

Das ist auch der Grund warum nach Warnungen oft nicht reagiert wird. Entweder, weil der Auftraggeber die Mail nicht weiterleitet, da er Zusatzkosten befürchtet für die er schon zu Projektstart nicht zahlen wollte, oder aber weil Verträge wie bereits erwähnt im Punkt Sicherheit oft sehr schwammig sind und es dann eine Disskusion gibt, ob Lücke XY noch in das vereinbarte Mindestmaß an Sicherheit reinfällt, oder nicht und wer entsprechend die Kosten tragen muss. Und solange dass nicht eindeutig geklärt ist und auch sonst nichts passiert, tut der Dienstleister natürlich überhaupt nichts.

Wenn dann eine Lücke wie in deinem Blogg veröffentlicht wird, geht es oft sehr schnell. Warum? Weil entweder der Auftraggeber Angst vor Schäden (und den damit verbundenen Kosten) bekommt und dann den Preis des Dienstleisters zahlt. Oder weil der Dienstleister fürchtet verklagt zu werden, den Prozess zu verlieren und Strafe zahlen zu müssen und nimmt die Kosten dann halt auf seine Kappe. Im Grunde also eine Nervenfrage, wer als erstes nachgibt.

Mich persönlich widert diese Praxis an, weswegen ich inzwischen auch den Job gewechselt habe. Aber andererseits muss man sich natürlich auch fragen warum Firmen und Organisationen die eigentlich das Geld dafür hätten, sowas wie Sicherheit kostenlos bekommen sollten. Immerhin hängen davon auf Dienstleisterseite, Arbeitsplätze ab.

Ich weiß jetzt natürlich nicht, welche Gründe dazu geführt haben, dass viele Seiten die irgendwie zum Bundestag gehören, so fehlerbehaftet sind. Mir ist es auch vollkommen egal wer der Schuldige ist, mir geht es nicht darum irgendjemanden am Kragen zu packen und in die Öffentlichkeit zu zerren. Mir geht es einzig und allein darum, dass die Verantwortlichen endlich einsehen, dass man so nicht weiter arbeiten kann.