© Nerlich Images, Fotolia.com

Wer Webapplikationen schreibt, sollte Acht geben auf Parameter in URLs und auf Cookie-Design. Sonst ergeht es ihm wie gleich dem Betreiber eines Onlineshops für Taschen. Bei dem bestimmt der Kunde nämlich die Preise. Eine kleine Einführung in praktische Sicherheit.

Wer die Weihnachtsgeschenke schon im November und online kauft, kann das nicht nur entspannter und ohne Last-Minute-Tütenschleppen tun, sondern auch zu guten Preisen. Der folgende Artikel zeigt beispielhaft an einem Onineshop, dass sogar das von orientalischen Basars bekannte Feilschen von Erfolg gekrönt sein kann – einige Computerkenntnisse vorausgesetzt. Mehr noch: Viele Preise lassen sich bis unter die Einkaufskonditionen des Onlinehändlers drücken, dank Sicherheitslücken.

Wer bei Hamosons [1], einem Anbieter von Aktentaschen (Abbildung 1), auf die Wunschtasche klickt, dem fällt ins Auge: Alle Parameter, inklusive Preis und Bild stehen in der URL. Da lohnt ein Angriffsversuch: Schnell einen besseren Preis in die URL-Zeile des Browsers eingefügt und schon gibts Rabatt. Der Shop erlaubt sogar negative Preise! Gleichzeitig kann der Angreifer alle beschreibenden Texte und auch das zugehörige Bild variieren. Abbildung 2 zeigt ein Beispiel.

Abbildung 1: Aktentaschen sind die Spezialität dieses Onlineshops, in Sachen Websicherheit ist die Expertise dagegen nicht so groß.

Abbildung 2: Plötzlich hat der Taschenschop einen Rettungshubschrauber im Angebot. Wer sich dafür entscheidet, bekommt noch 100 000 Euro raus.

Dabei bleiben die manipulierten Preise bis zum Ende des Bestellprozesses. Das bedeutet, dass der Shop dem Preis, den er sich permanent als Parameter übergibt, vertraut. Das einzige Risiko: Ein Mensch merkt beim Zusammenstellen der Bestellung, dass etwas nicht passt. Die Gefahr ist natürlich größer, taucht im Warenkorb ein nicht im Produktspektrum vorgesehener gebrauchter Rettungshubschrauber auf.

Um zu testen, ob ein falscher Preis wirklich einen echte Bestellung auslöst, hat das Linux-Magazin eine Tasche, die eigentlich 125 Euro kostet, für 135 Euro bestellt. Der gewählte Preis beim Testkauf ist höher als der reguläre, um den Händler nicht zu schädigen und um keine zivilrechtlichen Schadenersatzansprüche zu begründen. Und tatsächlich: Nach kurzer Zeit erhielt unser Testkäufer eine Bestätigungsmail mit dem getürkten Preis (siehe Listing 1).

01 From:  <info@hamoson.de>
02 Date: 2010/10/19
03 Subject: Ihre Bestellung auf www.hamosons.de
04 To: 
     
      [...]
     
05 
06 Vielen Dank für Ihre Bestellung.
07 Bei Nachname oder Kreditkartenzahlung erfolgt der Versand in der Regel binnen 3er Werktage.
08 
     
      [...]
     
09 ---------------------------------------------
10 Folgende Daten wurden bei uns vermerkt:
11 ---------------------------------------------
12 Artikel:        Aktentasche 302 opu-dunkel (Aktentasche gefüttert)
13 Anzahl: 1
14 Preis gesamt:   135,00 EUR
15 
     
      [...]
     
16 --------------------------------------------
17 Preis netto: 113,45 EUR
18 MwSt: 21,55 EUR
19 Preis brutto ohne Versandkosten: 135,00 EUR
20 --------------------------------------------
21 
     
      [...]
     
22 Wir bedanken uns für Ihre gute Wahl und wünschen noch viel Freude mit unserem Produkt.

Manipulierbare Cookies und ein SSL-Problem

Ein Onlineshop, der Preise per URL-Parameter übergibt und die Daten nicht aus einer Datenbank zieht, weist vielleicht noch andere Lücken auf. Eine Analyse der auf dem Client gesetzten Cookies ergibt: Ja, der gesamte Warenkorb inklusive Preisen und Stückzahl landet in mehreren Cookies. Die lassen sich fast genauso leicht manipulieren wie eine URL-Zeile, zum Beispiel mit den Tools Cookie Editor [2] oder FireBug [3].

Hamosons Web-Shop vertraut diesen Cookies, obwohl der PC des Endusers diese Daten speichert – ein wenig vertrauenswürdiger Ort. Richtig wäre auch hier, lediglich die Artikelnummern der gewünschten Produkte im Cookie abzulegen und die weiteren Ausgabedaten anhand der Artikelnummer aus der Shop-Datenbank zu ziehen.

Weiter zum Bezahlvorgang: Der Text auf der entsprechenden Seite suggeriert, die Kreditkartendaten würden verschlüsselt übertragen (Abbildung 3). Jedoch reicht das Formular die eingegebenen Daten weiter zu einer unverschlüsselten Seite – und die enthält bereits die Kreditkartendaten, wie die Auszüge in Listing 2 zeigen. Jeder, der die Kommunikation mithört, greift die Kreditkartendaten ab.

Abbildung 3: Auch wenn der Text es anders darstellt, die Kreditkartendaten laufen nicht SSL-verschlüsselt über die Leitung (siehe Listing 2).

01 <form method="POST" action="kasse.php?auswahl=1" align="center">
02 
     
      [...]
     
03     <td width="118" valign="middle"><div align="left">Kartennummer:</div></td>
04     <td width="221" valign="middle"><strong>
05       <input type="text" name="kartennr" size="30">
06 
     
      [...]
     
07     <td valign="middle">G&uuml;ltigkeitsdatum:</td>
08     <td valign="middle"><strong>
09       <input name="guedat" type="text" id="guedat" size="30">
10 
     
      [...]
     
11     <td valign="middle">Pr&uuml;fziffer:</td>
12     <td valign="middle"><strong>
13       <input name="prueziff" type="text" id="prueziff" size="30">
14 
     
      [...]

Moderne Kreuzzüge

Statt zu lauschen, verraten auch Cross-Site-Scripting-Angriffe diese Daten. Bei dieser Art der HTML-Injection nimmt eine Webanwendung Nutzerdaten ungeprüft an, um sie später in der Seite auszugeben. Das ermöglicht einem Angreifer, (Schadcode)-Skripte indirekt an den Browser von Opfern zu senden, der diesen dann ausführt. Der User ist sich dessen nicht bewusst, weil er meint, im Kontext einer vertrauenwürdigem Webseite zu agieren. [4]

Der simple Test in Listing 3. Er schleust über den URL-Parameter »foto« in das Bild einen »onMouseOver«-Handler ein. »foto« enthält die komplette URL des Bildes, das der Shop in der Warenkorb-Ansicht anzeigt. So kam vorher schon der Hubschrauber in den Warenkorb.

01 http://www.hamosons-aktentaschen.eu/shop/warenkorb.php?foto=../fotos/aktentaschen_gefuettert/h_1_timesquare_black303blk.jpg%22%20onMouseOver=alert(1);%20alt=%22&artikelnummer=Aktentasche%20303%20black&preis=125.00&bezeichnung=Aktentasche%20gef%FCttert&anzahl=1

Der »onMouseOver«-Handler führt eine Javascript-Aktion aus, sobald der Benutzer die Maus über das Objekt bewegt. Damit das funktioniert, darf der Handler natürlich nicht im »src«-Attribut des »img«-Tags auftauchen, sondern gehört hinter die schließenden Gänsefüßchen. Der originale PHP-Code der Seite sieht vermutlich so aus:

<img src="<? echo $foto; ?>">

Bei einem erfolgreichen XSS-Angriff sieht das Ergebnis in etwa so aus:

<img src="[...]" onMouseOver=alert(1);>

Da das Script den Parameter »foto« erst hinter den ersten Gänsefüßchen ausgibt, muss der eingeschleuste Code mit Anführungszeichen beginnen, um so das SRC-Attribut zu beenden. Dummerweise bleiben aber die ursprünglichen schließenden Anführungszeichen des SRC-Attributes an ihrem Fleck und führen zu einer Missinterpretation des HTML. Doch das lässt sich elegant lösen: Ein nutzerfreundliches »alt«-Attribut für die Grafik erledigt das. Für den Angriff muss »foto« folgenden Inhalt haben:

" onMouseOver=alert(1); alt="

Listing 3 schreibt dann in den Warenkorb folgenden HTML-Code:

<img src="[...]" onMouseOver=alert(1); alt="">

Nach dieser Maßnahme stimmt die Zahl der Gänsefüßchen wieder, und der Browser rendert die Seite korrekt.

Zwar hat der Webserver von Hamosons offensichtlich die PHP-Option »magic_quotes_gpc« gesetzt, die automatisch Anführungszeichen mit einem Backslash escaped und damit allzu plumpe Code- und SQL-Injections verhindert. Sie schützt aber gerade nicht vor einem Cross-Site-Scripting-Angriff, denn die meisten Browser ignorieren diesen Backslash. Der hat in HTML keine besondere Bedeutung. Dass der HTML-Quelltext nun etwas hässlicher als gewohnt aussieht, damit kann ein Angreifer leben.

Tolerante Browser und der »onLoad«-Kniff

Der Mouse Over wäre für einen echten Angriff auf Kreditkartendaten zu wenig verlässig, denn das Opfer muss die Maus über das Bild bewegen, um einen Effekt zu erzielen. Das Ziel soll darum sein, die Daten des Formulars, das die Kreditkartendaten enthält, so umzulenken, dass der Angreifer diese erhält. Ein Blick auf den Seitenaufbau offenbart zwei Formulare: Das obere, das den Warenkorb enthält und darüber Angriffen zugänglich ist, und das untere, in das der Kunde die Kredikartendaten eintippt.

Das bedeutet, dass eingeschleuster Code im oberen Formular das untere Formular beeinflussen können muss. Dazu bietet sich ein Javascript an, das den Action-Parameter manipuliert, der angibt, wohin der Browser die Formulardaten sendet. Hier sind verschiedene Optionen denkbar. Die einfachste ist eine Umleitung der Formulardaten auf den Server des Angreifers mittels der Javascript-Direktive »document.forms[1].action=”…”«. Da aber nur das obere Formular verwundbar ist, läuft ein zu plumpes Skript ins Leere. Das liegt daran, dass es im Moment der Ausführung das zweite Formular »forms[1]« nicht erreicht, weil die Seite noch nicht vollständig geladen ist.

Der Browser darf den Javascript-Befehl also erst ausführen, wenn die Seite vollständig geladen ist. Dafür spezifiziert Javascript einen »onLoad«-Handler. Allerdings funktioniert der nur im »body«-Tag – und das ist schon geschrieben, wenn das Warenkorb-Formular vorbeikommt. Zum Glück gehen die meisten Browser mit gruseligem HTML aber sehr entspannt um und führen auch den »onLoad«-Handler im »body«-Tag aus.

Die Nummer mit der Artikelnummer

Auch der Hamosons-Webshop zeigt sich kooperativ, denn er prüft Eingabedaten überhaupt nicht. So lässt sich beliebiger HTML-Code einschleusen. Listing 4 zeigt ein Beispiel für diese Art der Code-Injection. Die folgende Simulation eines Angriffs nutzt den Text für die Artikelnummer und fügt anstelle der Artikelnummer den HTML-Tag

<body onLoad=document.forms[1].action=1 />

ein. Und tatsächlich: Sobald die Seite fertig geladen ist, wechselt die Zieladresse des Formulars auf »1«, wie sich mit dem DOM-Inspector des Browsers beobachten lässt. Echte Angriffe würden zum Beispiel ein Script von einem entfernten Rechner nachladen, indem sie einfach ein »<script src=”…”>«-Tag benutzen.

01 http://www.hamosons-aktentaschen.eu/shop/warenkorb.php?foto=../fotos/aktentaschen_gefuettert/h_1_timesquare_black303blk.jpg&artikelnummer=%3Cbody%20onLoad=document.forms[1].action=1%20/%3E&preis=1.00&bezeichnung=bla&anzahl=1

Falls bestimmte, für den Angriff nötige Zeichen verboten sind, hilft die »eval«-Funktion von Javascript. Sie berechnet erst einen übergebenen Ausdruck und führt ihn dann als Javascript aus. Damit ist fast jede kunstvolle Codierung [5] machbar, so auch eine, die die von »gpc_magic_quotes« misshandelten Gänsefüßchen elegant umgeht.

Die Moral der Geschichte

Er war nicht das primäre Ziel dieses Beitrags, einen Aktentaschenhändler vorzuführen. Der Artikel will vielmehr Webprogrammierern die Techniken von Angreifern demonstrieren, damit sie ihre Software von vornherein gegen solche Manipulationsversuche wappnen.

Das ist schwer: Würde das Shopsystem von Hamosons nicht permanent alle Daten dem User zusenden und darauf vertrauen, dass sie unverändert zurückkommen, wäre viel gewonnen. Wenn die Middleware die Preise und Artikelbeschreibungen dann noch aus einer Datenbank zöge, entfielen alle gezeigten Angriffsvektoren. Generell empfiehlt es sich, Eingaben auf Plausibilität zu prüfen und illegale sowie gefährliche Zeilen zu ersetzen. Dafür gibt es zum Beispiel die PHP-Funktion »htmlentities()«, die zumindest den simplen Body-Tag-Angriff von oben erschwert.

Im Zuge der Recherchen zu seinem Beitrag hat der Autor den Betreiber des Hamosons-Shops auf die Sicherheitslücken hingewiesen. Der nahm den Hinweis zur Kenntnis, ohne jedoch Maßnahmen einzuleiten. Das Linux-Magazin wird dem Anbieter eine Woche vor Veröffentlichung den Artikel zu Verfügung stellen. (jk)