Web-Sicherheitslücken am Beispiel eines Onlineshops

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: <emphasize>[...]</emphasize>
05 
06 Vielen Dank für Ihre Bestellung.
07 Bei Nachname oder Kreditkartenzahlung erfolgt der Versand in der Regel binnen 3er Werktage.
08 <emphasize>[...]</emphasize>
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 <emphasize>[...]</emphasize>
16 --------------------------------------------
17 Preis netto: 113,45 EUR
18 MwSt: 21,55 EUR
19 Preis brutto ohne Versandkosten: 135,00 EUR
20 --------------------------------------------
21 <emphasize>[...]</emphasize>
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 <emphasize>[...]</emphasize>
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 <emphasize>[...]</emphasize>
07     <td valign="middle">G&uuml;ltigkeitsdatum:</td>
08     <td valign="middle"><strong>
09       <input name="guedat" type="text" id="guedat" size="30">
10 <emphasize>[...]</emphasize>
11     <td valign="middle">Pr&uuml;fziffer:</td>
12     <td valign="middle"><strong>
13       <input name="prueziff" type="text" id="prueziff" size="30">
14 <emphasize>[...]</emphasize>

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.