News Drucken: SQL-Injection-Angriffe, wohin man blickt

In letzter Zeit treten besonders häufig SQL-Injection-Angriffe auf, hier ein Überblick und mögliche Gegenmaßnahmen. Über die SQL-Injection-Angriffe, die ASP/ASP.NET-Anwendungen mit JavaScript-Code zum Nachladen von Exploits für verschiedenen Schwachstellen verseucht haben, hatte ich ja bereits am 28. April im Standpunkt Sicherheit berichtet. So wurden z.B. auch die EPG-Daten der ARD manipuliert (siehe auch Standpunkt Sicherheit vom 13. Mai).

Ein Überblick

Die Entwicklung lässt sich z.B. gut im F-Secure Weblog verfolgen:

24. April: Mass SQL Injection
10. Mai: SQL Injection Continues
13. Mai: SQL Injection Attacks Becoming More Intense
28. Mai: Flash w/ SQL

Oder auch bei Dancho Danchev:

17. Mai: Redmond Magazine SQL Injected by Chinese Hacktivists
19. Mai: Fast-Fluxing SQL Injection Attacks

Fast-Fluxing SQL injection attacks executed from the Asprox botnet

22. Mai: Malware Domains Used in the SQL Injection Attacks
26. Mai: Yet Another Massive SQL Injection Spotted in the Wild

Laut einer Meldung von Heise Security sind inzwischen auch deutsche Websites vermehrt Opfer dieser Angriffe.

Der Angriff

Ein ähnlicher Angriff lief bereits im Januar, die damals verwendeten Methoden wurden vom Internet Storm Center analysiert. Die aktuellen Angriffe folgen dem gleichen Muster: Über SQL-Injection werden alle geeigneten Datenbankfelder mit JavaScript-Code zum Nachladen von Schadcode gefüllt, in der Hoffnung, dass mindestens eines der Felder ohne weitere Prüfung an die Besucher der Webseite ausgegeben wird.

Dabei werden Systemtabellen und z.B. rein numerische Felder ignoriert und nur einem normalen Benutzer gehörende Tabellen und darin Felder mit Textwerten etc. manipuliert. Werden die Werte daraus dann später ohne weitere Bearbeitung oder Filterung an den Benutzer der Webanwendung ausgegeben, wird darüber Schadcode zum Ausnutzen verschiedener Schwachstellen nachgeladen. Aktuell handelt es sich dabei z.B. auch um die aktuellen Exploits für Adobes Flash-Player, siehe den Standpunkt Sicherheit vom 2. Juni.

Gegenmaßnahmen

Außer dem Rat aus dem Standpunkt Sicherheit vom 28. April, die Logfiles nach dem SQL-Injection-Code zu durchsuchen und ggf. eingeschleusten Schadcode aus der Datenbank zu entfernen sowie die SQL-Injection-Schwachstelle in der Webanwendung zu beheben, gibt es drei weitere Schutz- bzw. Gegenmaßnahmen: Zum einen ist der SQL-Injection-Angriff nur erfolgreich, wenn das Benutzerkonto, mit dem die Webanwendung auf die Datenbank zugreift, die Datenbank auch verändern darf. Sind keine Änderungen an der Datenbank notwendig, sollten dem entsprechenden Benutzer alle Rechte außer den notwendigen Leserechten entzogen werden. Zum anderen kann eine Web Application Firewall die SQL-Injection-Angriffe erkennen und abwehren, bevor sie die Webanwendung erreichen.

Außer diesen relativ einfach zu implementierenden Schutzmaßnahmen gibt es noch eine aufwendigere Gegenmaßnahme: Für alle auszugebenden Daten können die gleichen Prüfungen wie für vom Benutzer gelieferte Daten angewendet werden. Unerwünschter JavaScript-Code würde dabei erkannt und ausgefiltert bzw. unbrauchbar gemacht. Am einfachsten ist das für Daten umzusetzen, die keinem HTML- und/oder JavaScript-Code enthalten dürfen. Dann reicht schon das simple Umwandeln von < und > in die entsprechenden HTML-Entities < und >, um unerwünschten Skriptcode unbrauchbar zu machen. Das hat zwar den unschönen Nebeneffekt, das der so entschärfte Schadcode als Quelltext im Browser des Benutzers ausgegeben wird, aber zumindest kann er keinen Schaden mehr anrichten.

Carsten Eilers