HUDU

Security im E-Commerce


€ 9,99
 
pdf eBook
Sofort lieferbar (Download)
Juli 2014

Beschreibung

Beschreibung

Das Buch richtet sich besonders an Webentwickler und IT-Entscheider, die eine E-Commerce-Seite betreiben wollen oder dies bereits schon tun.Es werden neben den häufigsten Angriffsszenarien wie XSS, Injection oder CSRF auch Exoten wie Pixel Perfect Timing beschrieben und mögliche Verteidigungsmethoden besprochen. Die Beispiele beruhen dabei auf der langjährigen Erfahrung des Autors und sind zum Großteil auch für Applikationen außerhalb des E-Commerce wie CMS-Projekte, Blogs oder Intranetapplikationen interessant.Zudem werden Frameworks und Tools analysiert, die helfen, Ihre Applikation mit möglichst geringem Aufwand abzusichern.

Portrait

Tobias Zander ist CTO und Partner bei Sitewards in Frankfurt a. M., dem Spezialisten für E-Commerce im Rhein-Main-Gebiet. Davor hatte er als freier Berater und Softwarearchitekt lange Jahre Gelegenheit, viele verschiedenen Stile und Methoden der Softwareentwicklung kennenzulernen und weiterzuentwickeln. Tobias inspiriert weltweit PHPEntwickler als Speaker auf Konferenzen wie z. B. MagentoLive, IPC oder verschiedenen Barcamps und User Groups. Und wenn es die Zeit erlaubt, schreibt er für verschiedene Magazine, wie z. B. t3n oder PHP Magazin.

Leseprobe

2 Cross-Site Scripting

Eines der Hauptprobleme in heutigen Webapplikationen ist und bleibt Cross-Site Scripting. Der Name ist dabei etwas verwirrend, denn die darunter verstandenen Angriffsszenarien müssen gar nicht durch eine zweite Seite stattfinden oder von dort Daten laden. Die Angriffe finden häufig auf einer einzelnen Seite statt, indem dort HTML-, CSS- oder JavaScript-Code eingefügt wird und im Idealfall persistent vorhanden ist, indem der Angriff in der Datenbank, Session oder in Cookies gespeichert wird.

Technisch gesehen gehört eine XSS-Attacke sogar zum großen Teil der Injections (Kapitel 3.1), da die Problematik aber so groß und weit verbreitet ist, wurde ihr hier ein eigenes Kapitel gewidmet.

2.1 Die Gefahr

Das klingt jetzt alles spannend, aber was kann denn wirklich passieren?

2.1.1 Defacing

Das wohl noch kleinere Übel ist das Defacing einer Website. Häufig rühmt sich der Angreifer dann damit, eine Website gehackt zu haben, und hinterlässt seine „Tags“. Farben oder Texte werden manipuliert, die Änderungen sind aber zumeist sofort erkennbar, da der Hack Aufmerksamkeit erregen soll.

Möglich ist es aber auch, das Ganze etwas subtiler zu machen, so kursieren aktuell mehrere Fälle im TYPO3-Umfeld, bei denen sich der Content dynamisch ändert, je nachdem, über welche Suchbegriffe man auf die Website gekommen ist. Dies wird dazu genutzt, um damit dann z. B. über Ihre Website quasi unbemerkt Viagra oder andere zwielichtige Güter zu bewerben und verkaufen. Dies wird häufig erst erkannt, wenn man selbst über entsprechende Suchergebnisse auf die Website trifft oder die Logs genauer untersucht, um herauszufinden, mit welchen Suchbegriffen auf die Seite gelangt wurde.

2.1.2 Datenmanipulation

Etwas weiter gehen die Attacken dann, wenn bösartiger JavaScript-Cod
e eingefügt wird, der z. B. Requests ausführt, die via AJAX ausgelöst werden, und dadurch die Daten manipuliert.

Ruft dann ein User die Seite auf, können dadurch z. B. seine E-Mail-Adresse oder Informationen in seinem Profil geändert werden, ohne dass er davon etwas mitbekommt. Letzteres wird in Kapitel 3.3.3 mit einer XSS-/CSRF-Kombination auf die Spitze getrieben.

Hat der User Administrationsrechte, wäre es sogar möglich, automatisiert z. B. einen neuen Account anzulegen oder einem bestehenden Account mehr Rechte zu geben, wenn der Angreifer genügend Informationen über die benötigten Requests hat.

Prinzipiell ist aber auch die Manipulation von Seiten denkbar, wenn man auf einen Redakteur trifft, oder die Änderung des Rankings in einem Suchalgorithmus, oder eventuell das Setzen von Links auf die Seite der Konkurrenz.

2.1.3 Datenspionage

Doch kann das Ausspionieren von Daten weitaus schlimmere Folgen haben als die Manipulation. Während Letztere doch sicherlich entdeckt werden kann, bleiben Spione oft jahrelang unentdeckt, geben sensitive Firmeninformationen preis oder tracken einfach jegliche Aktion des kompromittierten Clients.

So sind nicht nur die Daten auf der angegriffenen Website in Gefahr, und zwar sämtliche, egal welche Userrechte benötigt werden, sondern auch viele Informationen über den Client: Wie benutzt er die Website, wann besucht er sie und welche sonstigen Systeme sind über ihn im Netzwerk erreichbar? Details zum Scannen eines internen Netzwerks mithilfe einer XSS-Lücke finden Sie in Kapitel 2.1.5.

2.1.4 XSS-Proxy

Das Ganze wird durch XSS-Proxies zur Perfektion getrieben. So gibt es inzwischen voll ausgebaute Applikationen, um über XSS-Lücken ganze Bot-Netze durch die kompromittierten Browser aufzubauen und nicht nur die gehackte Website zu schädigen, sondern darüber z. B. auch sehr gut nache
mpfundene Log-ins für weitere Dienste wie Facebook einzublenden, die dann natürlich nach Hause telefonieren, oder auch mal nahezu unbemerkt die Webcam des Users zu aktivieren.

Sehr clever ist dabei, dass diese XSS-Proxies sich persistent auf der Website einnisten. Sobald sie einmal geladen sind, tauschen sie alle Link-Tags durch AJAX-Requests aus. Normalerweise wäre ein XSS-Hack nutzlos, sobald die betroffene Seite verlassen wird, da der JavaScript-Code komplett geleert und das Script angehalten wird. Durch den Austausch der Links werden die Inhalte beim Klick auf einen der Links zwar geladen und dem Client angezeigt, sodass der User zunächst nichts bemerkt. Da der Content aber im Hintergrund geladen wird und kein komplettes Neuladen der Seite erfolgt, bleiben der JavaScript-Code und somit auch der XSS-Proxy weiterhin geladen und können somit auch später noch Informationen ausspionieren, obwohl diese Seiten eigentlich gar keine XSS-Lücke enthalten. Am Beispiel des BeEF-Projekts zeigen wir in Kapitel 7.4 wie solch ein XSS-Proxy aussehen kann.

2.1.5 Angriff auf Drittsysteme

Allerdings ist nicht nur die ursprünglich gehackte Website in Gefahr, denn von ihr können u. a. auch Requests an ein internes Netz (eine interne Jira-Instanz, Forum oder Router) abgesetzt werden. Die Same Origin Policy verhindert dabei zwar, dass die Response ausgelesen werden kann, der Request wird aber trotzdem abgesetzt, so wird eine Abfrage gesendet und es werden Funktionen ausgeführt. In Kombination mit einer Time-based SQL Injection (Kapitel 3.1.1) ist es dann weiterhin möglich, auch Daten aus einem internen System auszulesen.

Jetzt aber genug zur Theorie, denn Sie wollen sicherlich praktische Beispiele und Quellcode sehen?

2.2 XSS-Typen

XSS-Lücken werden in drei verschiedene Typen unterteilt, die im Folgenden im Detail beschrieben werden.

2.2.1 Type 0/DOM-based XSS

Unter dem Ty
pe 0 oder auch DOM-based oder lokaler XSS versteht man einen Angriff auf das DOM-Objekt im Browser. Der Angriff wird dadurch ausgeführt, dass die DOM-Umgebung des Opfers manipuliert wurde und der ursprüngliche Code ein unerwartetes Verhalten zeigt. Der Quellcode der Seite ändert sich also nicht, allerdings wurden die Daten manipuliert, auf die zugegriffen wird.

Am einfachsten lässt sich dies an einem kleinen Beispiel zeigen, wenn man folgenden Quellcode annimmt:


Normalerweise wird die Seite also mit etwa folgendem URL aufgerufen:

http://www.example.com/index.php?def=Deutsch

Eine Attacke könnte nun aber passieren, wenn der URL z. B. folgendermaßen abgeändert wird:

http://www.example.com/index.php?def=

Die Response enthält dann an der Stelle, an der normalerweise die Sprache innerhalb des -Tags stehen sollte, JavaScript-Code, der den Inhalt der Cookies ausgibt.

2.2.2 Type 1/nicht persistente Schwachstelle

Eine nichtpersistente oder auch reflektierte Schwachstelle ist wohl die weit verbreitetste Art von XSS.

Ein typisches Beispiel ist eine Suchmaschine, die den Such-String noch einmal in der Headline oder auch als vordefinierten value ausgibt. Das soll an einem Beispiel demonstriert werden:


Normalerweise sollte dieses Formular einen URL erzeugen, der etwa folgenermaßen aussieht:

http://www.example.com/index.php?sword=foobar

Nun wird statt des Suchworts wiederum JavaScript-Code übergeben:

http://www.example.com/index.php?sword=

So wird statt der Ausgabe des eigentlichen Suchbegriffs wiederum die Informationen der Cookies ausgegeben.

Der entsprechende URL kann dabei auch z. B. einem unwissenden Opfer untergejubelt werden, indem von einer modifizierten Seite mit dem manipulierten Suchbegriff verlinkt oder der Link per Forum oder E-Mail verteilt wird.

Besonders häufig tritt diese Art von Schwachstelle auch bei konfigurierbaren Produkten auf, die z. B. die Übergabe einer Farbe oder eines Namens erlauben, der nicht weiter validiert und so direkt an den Browser ausgegeben wird.

2.2.3 Type 2/persistente Schwachstelle

Persistente oder auch Second-Order-Schwachstellen werden als Type 2 kategorisiert und sind gleichzeitig die wohl gefährlichsten aller möglichen XSS-Attacken.

Von Type 1 unterscheidet sich dieser Angriff dadurch, dass die übermittelten Daten in irgendeiner Art und Weise auf dem Server gespeichert werden. Sehr häufig sind hier z. B. Datenbanksysteme oder Cache-Server.

Auf E-Commerce-Seiten sind besonders Kommentar- und Bewertungssysteme betroffen, die es den Nutzern erlauben, HTML-formatierten Text zu speichern und anderen...


EAN: 9783868023169
Untertitel: Absicherung von Shopsystemen wie Magento, Shopware und OXID. Dateigröße in MByte: 6.
Verlag: entwickler.press
Erscheinungsdatum: Juli 2014
Seitenanzahl: 164 Seiten
Format: pdf eBook
Kopierschutz: Wasserzeichen
Es gibt zu diesem Artikel noch keine Bewertungen.Kundenbewertung schreiben