20.12.2013 Aufrufe

Sicherheit von SAP in Bezug auf neue Technologien

Sicherheit von SAP in Bezug auf neue Technologien

Sicherheit von SAP in Bezug auf neue Technologien

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

<strong>Sicherheit</strong> <strong>von</strong> <strong>SAP</strong> <strong>in</strong> <strong>Bezug</strong> <strong>auf</strong> <strong>neue</strong> <strong>Technologien</strong><br />

Cross-Site-Script<strong>in</strong>g f<strong>in</strong>det üblicherweise über JavaScript statt,<br />

grundsätzlich ist aber jeder vom Browser ausgefürhrte Code geeignet.<br />

SQL-Injection<br />

SQL-Injection gehört zu e<strong>in</strong>er der potentiell gefährlichsten Attacken, da<br />

hierdurch unternehmenskritische oder sonstige wichtigen Daten offen<br />

liegen können, wie z.B. Kreditkartennummern <strong>von</strong> Kunden. Weniger<br />

bekannt aber ähnlich gefährlich ist, dass viele<br />

Datenbankmanagementsysteme Schnittstellen für<br />

Betriebssystemkommandos bereitstellen, wie xp_cmdshell des MS SQL<br />

Servers, der <strong>in</strong> der Vergangenheit standardmäßig mit adm<strong>in</strong>istrativen<br />

Rechten <strong>auf</strong> dem Betriebssystem lief.<br />

Ursache für SQL-Injection ist häufig, dass Benutzere<strong>in</strong>gaben Teil e<strong>in</strong>es SQL-<br />

Befehls an das Backend s<strong>in</strong>d. Die Webapplikation wirkt hierbei also als<br />

Interface für SQL-Befehle. Das Gefährliche ist, dass hier die Möglichkeiten<br />

der E<strong>in</strong>gabe über das vom Programmierer Erwartete h<strong>in</strong>ausgehen. Erwartet<br />

wird für gewöhnlich e<strong>in</strong>e Benutzere<strong>in</strong>gabe, die im späteren SQL-Befehl<br />

e<strong>in</strong>en Parameterwert oder e<strong>in</strong>en Teil dessen darstellt, z.B. e<strong>in</strong><br />

Benutzername. Es ist aber möglich, die erwartete E<strong>in</strong>gabe zu verändern<br />

oder zu erweitern, so dass anstatt des Parameterwertes, der eigentlich<br />

erwartet wurde, e<strong>in</strong> Teil e<strong>in</strong>es SQL-Befehls entsteht, der den ursprünglichen<br />

SQL-Befehl verändert, oder aber auch e<strong>in</strong> <strong>neue</strong>r SQL-Befehl bzw. e<strong>in</strong>e<br />

Verkettung <strong>von</strong> SQL-Befehlen.<br />

E<strong>in</strong> oft beschrittener Weg bei e<strong>in</strong>er gefundenen SQL-Injection<br />

Schwachstelle ist es, zunächst die Systemtabellen auszulesen. Da e<strong>in</strong><br />

relationales Datenbanksystem alle Informationen auch über sich selbst<br />

auch <strong>in</strong> se<strong>in</strong>en Tabellen speichern muss, können hier alle gewünschten<br />

Informationen über die Datenbank ausgelesen werden, die Möglichkeit der<br />

E<strong>in</strong>gabe der entsprechenden Befehle und die notwendigen Rechte<br />

vorausgesetzt. Danach können die gewünschten Informationen wie z.B.<br />

Kreditkartennummern gezielt abgefragt werden oder andere gewünschte<br />

Aktionen wie das gezielte Verändern <strong>von</strong> Datenbanke<strong>in</strong>trägen durchgefürt<br />

werden.<br />

Auch bei SQL-Injection gibt es e<strong>in</strong>e weitere Variante, die Bl<strong>in</strong>d-SQL-<br />

Injection. Während man bei e<strong>in</strong>er gewöhnlichen SQL-Injection den Aufbau<br />

des vom System verwendeten SQL-Befehls anhand <strong>von</strong> Fehlermeldungen<br />

erkennen kann, ist dies bei Bl<strong>in</strong>d-SQL-Injection nicht möglich. E<strong>in</strong> Angreifer<br />

muss sich daher den korrekten Aufbau des SQL-Befehls anhand <strong>von</strong><br />

Damian Schlager Seite 25

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!