Die beliebtesten Angriffsziele der Internetkriminellen sind nicht die großen Unternehmen. Täglich attackieren sie kleine und mittlere Webshops und –sites. Sie suchen nach Kunden- und Benutzerdaten, schleusen Malware ein oder bringen den Webserver unter ihre Kontrolle. Am häufigsten nutzen Hacker SQL-Injections und Cross-Site-Scripting. Diese Sicherheitslücken sollten verantwortungsbewusste Webshop- und Websitebetreiber daher schließen.
Banken, Software-Giganten oder andere große Unternehmen investieren viel Zeit und Geld in die Sicherheit ihrer Server. Sollte doch ein Angriff gelingen, so werden die Systeme rund um die Uhr überwacht und ein Einbruch schnell erkannt. Die Sicherheitslücke wird innerhalb weniger Minuten geschlossen. Hacker wissen, bei großen Unternehmen sind die Chancen auf Profit zu gering.
Daher nehmen Internetkriminelle vor allem die Websites kleiner oder mittelständischer Unternehmen ins Visier. Kleine Internethändler schützen ihre Sites nicht in gleichem Maße wie eine Bank. Ihnen fehlt das Know-How oder das Geld für Programmierer. Diese Händler greifen zu konfektionierten Shop-Lösungen. Dadurch sind sie anfällig für Hackerangriffe.
SQL-Injection
Webshops oder Content-Management-Systeme setzen Datenbanken ein, um darin Kundendaten, Artikel und Texte abzulegen. Bei einer SQL-Injection schleust der Angreifer eigene Befehle in die Datenbank des Opfers ein. Dafür nutzt er dessen Webformulare, in die Benutzer Informationen eingeben, etwa um Bestellungen aufzugeben oder sich als Kunde zu registrieren.
Aus diesen Eingaben erzeugt eine Web-Applikation dynamische Datenbankanfragen. Werden dabei die Eingaben von der Web-Applikation nicht ausreichend überprüft, ist die Datenbank gefährdet. Dann ist es nämlich möglich, durch die Eingabe spezieller Zeichenketten in diese Formulare auf Inhalte und sogar das System der Datenbank zuzugreifen. Ein Beispiel: Der SQL-Befehl
SELECT * FROM
customer WHERE card = ’visa’
liefert alle Datensätze der Tabelle „customer“ aus, die in der Spalte „card“ dem Wert „visa“ entsprechen. Wird die konstante Zeichenkette „visa“ durch eine Variable „$card“ ersetzt, sind in Verbindung mit einer Benutzereingabe unterschiedliche Zeichenketten möglich. Werden Werte wie „visa“, „amex“ oder „master“ eingegeben, reagiert die Datenbank erwartungsgemäß. Bei der Eingabe von „’;DROP TABLE CUSTOMER–“ sieht die Datenbank jedoch zwei Befehle, da das Semikolon für sie ein Trennzeichen darstellt:
-
SELECT * FROM customer WHERE card = ’’ -
DROP TABLE CUSTOMER – ‘
Die Datenbank führt beide Befehle aus, wobei der zweite die Tabelle „customer“ löscht.
Um in dieser Art auf Inhalte oder das ganze System der Datenbank zugreifen zu können oder sie zu verändern, muss der Angreifer die Struktur der Datenbank kennen. Diese kann er herausfinden, indem er durch gezielte Eingaben Fehlermeldungen der Web-Applikation provoziert. Hat der Hacker genug Fehlermeldungen erhalten, kennt er auch den Aufbau der Datenbank.
Schutz vor SQL-Injections
Um SQL-Injections zu verhindern, müssen die Eingaben in Webformulare sorgfältig geprüft werden. Ein Filter schließt dabei gefährliche Zeichenketten aus, bevor die Applikation sie an die Datenbank sendet. Für die Einstellung des Filters gibt es zwei Strategien:
- „Deny all, allow some“-Strategie: Ist die Anzahl der möglichen Benutzereingaben eindeutig bestimmbar, so sind nur diejenigen erlaubt, die in einer definierten Liste geführt werden (zum Beispiel: Alter, Geschlecht, Bundesland)
„Allow all, deny some“-Strategie: Sind die Benutzereingaben nicht eindeutig vorhersehbar, so wird die Einstellung des Filters schwieriger (zum Beispiel: Name, Telefonnummer). In solchen Fällen bestimmt der Seitenbetreiber, dass definierte Elemente, etwa Semikolon oder Bindestriche, nicht in der Eingabe enthalten sein dürfen. Andernfalls verwirft die Applikation die Eingabe.
Eine weitere Methode ist der Einsatz von Prepared SQL-Statements. Dabei erstellt der Programmierer Templates der erwünschten Befehle. Die Daten werden dadurch nur noch als Parameter an einen bereits kompilierten Befehl übertragen. Unerwünschte SQL-Befehle nachträglich einzuschleusen, wird so unterbunden.
Cross-Site-Scripting
Bei Hacker-Angriffen mittels Cross-Site-Scripting, kurz XSS, wird dem Internetbrowser unsicherer Inhalt, also ein bösartiges Script, in einer vertrauenswürdigen Umgebung „untergejubelt“. Der Browser führt dadurch das bösartige Script automatisch aus. Der Hacker ist nun dazu in der Lage, Cookies des Opfers einzusehen, zu manipulieren und zu löschen. Die Folgen können weitreichend sein, da in Cookies Benutzerdaten wie Passwörter gespeichert werden.
Ausgangspunkt ist eine nicht ausreichend gesicherte Web-Applikation, die dynamische Seiten ausliefert. Gefahr entsteht, sobald der Seitenbetreiber seinen Besuchern ermöglicht, Inhalte einzustellen (zum Beispiel: Foren, Gästebücher, Kommentare). Die Angreifer können das bösartige Script einfach in einer Nachricht verpacken:
Der Browser stuft die Website als vertrauenswürdig ein und führt das Script aus.
Oder der Hacker führt seine Opfer mittels Link zu vertrauenswürdigen Seiten, die allerdings anfällig für XSS-Attacken sind (zum Beispiel durch Spam-Mails). Das bösartige Script ist im Link enthalten. Gibt der vertrauenswürdige Server das Script als Inhalt wieder aus, so erkennt der Browser es nicht als Text und führt es aus.
Schutz vor Cross-Site-Scripting
Die Besucher von Websites könnten sich durch das Deaktivieren aller Skripting-Funktionen vor XSS-Angriffen schützen. Da dadurch aber viele Seiten nicht mehr korrekt dargestellt werden, ist diese Variante des Schutzes ungeeignet. So bleibt den Besuchern nur, darauf zu achten, stets die neuesten Updates ihres Browsers installiert zu haben. Damit verbunden ist die Hoffnung, dass alle Sicherheitslücken im Browser geschlossen wurden. Der c’t-Browsercheck gibt über Sicherheit und Unsicherheit des Internetbrowsers Aufschluss.
Die Seitenbetreiber müssen grundsätzlich allen fremden Inhalten misstrauen und diese filtern. Dabei sollten nicht nur „böse“ Eingaben definiert und diese herausgefiltert werden. Besser ist es, sichere Eingaben zu definieren und nur solche zuzulassen. Wird dabei festgestellt, dass ein Inhalt nicht in das zulässige Muster passt, so sollte er auf keinen Fall nochmals ausgegeben werden. Das heißt, keine Fehlermeldungen wie „Ihre Eingabe XY ist ungültig“.
Hilfestellungen beim Schutz vor SQL-Injections und Cross-Site-Scripting
Beim Aufspüren von Sicherheitslücken auf Websites helfen sogenannte Schwachstellen-Scanner. Sie überprüfen Applikationen und Datenbank-Produkte auf mögliche Angriffspunkte für SQL-Injections und Cross-Site-Scripting. Es gibt eine Liste von gängigen kommerziellen und Open Source-Schwachstellen-Scannern.
Web Application Firewalls (WAF) versprechen umfassenden Schutz vor SQL-Injections und Cross-Site-Scripting. OWASP hat eine 25seitige Anleitung über Funktionsweise, Nutzen und Auswahlkriterien zu WAFs (PDF Datei).
Auch das Bundesamt für Sicherheit in der Informationstechnik warnt vor den Gefahren unzureichend gesicherter Web-Applikationen und veröffentlichte den Beitrag Sicherheit von Webanwendungen: Maßnahmenkatalog und Best Practices (PDF Datei). Darin werden neben den Gefahren durch SQL-Injections und Cross-Site-Scripting noch weitere Bedrohungen im Netz geschildert sowie Schutzmaßnahmen erläutert. ™
Erstveröffentlichung 19.08.2008
