SQL-Injektionsangriff

Eintrag zuletzt aktualisiert am: 19.08.2014

Ein SQL-Injektionsangriff (SQL Injection) bedeutet, dass es einem Angreifer gelingt, SQL-Befehle, die eine Anwendung verwendet, zu verändern oder durch eigene Befehle zu ersetzen, um dadurch von dem Entwickler der Anwendung nicht gewünschte Befehle auf der Datenbank auszuführen. Möglich ist dieser Angriff, wenn ihre Anwendung Benutzereingaben oder sonstige ungeschützte Informationen (z.B. URL-Parameter oder unverschlüsselte Cookies) als Eingabeparameter in SQL-Befehlen verwendet.

Angriffsbeispiel

Ein typisches Beispiel ist ein SQL-Befehl wie
SELECT * FROM Benutzer WHERE BName = '" + Name.Text + "' and BKennwort = '" + Kenn-wort.Text + "'"
mit dem geprüft werden soll, ob es die angegebene Kombination aus Benutzername und Kennwort in der Datenbank gibt, mit der gleichzeitig Daten über die betreffenden Benutzer abgerufen werden.
Benutzername und Kennwort werden üblicherweise in einem Anmeldedialog von dem Endbenutzer einge-geben. Die beiden folgenden Bildschirmdarstellungen zeigen zwei mögliche Eingaben. In beiden Fällen wird das Kennwort absichtlich in diesen Bildschirmdarstellungen offen angezeigt.
Eine Eingabe wie
' or 1=1 --
stellt einen Angriff in Form einer SQL Injection dar.

Daraus entsteht beim Zusammenbau des SQL-Befehls folgende Anweisung
SELECT * FROM Benutzer WHERE BName = 'HS' and BKennwort = ' ' or 1=1 -- '

Dieser SQL-Befehl wird immer alle Datensätze, die es für den Benutzer »HS« gibt, zurückliefern, da der Ausdruck 1=1 immer wahr ist. Das Ergebnis ist, dass der Benutzer erfolgreich angemeldet werden kann, obwohl er das richtige Kennwort gar nicht kennt. Die beiden Striche am Ende der Eingabe des Angreifers sind Kommentarzeichen und sorgen dafür, dass der Rest des ursprünglichen SQL-Befehls ignoriert wird.

Ein Angreifer könnte auch auf diese Weise noch viel gefährlichere SQL-Befehle ein-schleusen, z.B.
'; DROP TABLE Benutzer –

Schutz vor SQL-Injektionsangriffen

Gegen solche SQL-Injektionsangriffe schützt man sich durch zwei Maßnahmen:

• Verwendung parametrisierter Abfragen und der Parameters-Menge anstelle des Zusammenbaus von SQL-Befehlen aus Zeichenketten
• Filtern aller potentiell gefährlichen Zeichen, insbesondere des einfachen Anführungszeichens, aus der Eingabe

Grundsätzlich reicht eine der beiden Maßnahmen. Getreu dem Motto "Sicher-ist-Sicher" kann aber auch die Verwendung beider Maßnahmen nicht schaden.

Dim SQL = "SELECT * FROM bBenutzer WHERE " & "B_Name = ? And BKennwort = ?"
DS = New System.Data.DataSet
DA = New System.Data.OleDb.OleDbDataAdapter(SQL, (CONNSTRING))
'Dim p As New OleDbParameter
DA.SelectCommand.Parameters.Add("@Name", System.Data.OleDb.OleDbType.VarChar, 30).Value = name
DA.SelectCommand.Parameters.Add("@Kennwort", System.Data.OleDb.OleDbType.VarChar, 30).Value = kennwort
Listing: Verwendung parametrisierter Abfragen und der Parameters-Menge anstelle des Zusammenbaus von SQL-Befehlen aus Zeichenketten

name = SafeSql(name)
kennwort = SafeSql(kennwort)
Dim SQL = "SELECT * FROM bBenutzer WHERE " &
"BName = '" & name &
"' and B_Kennwort = '" & kennwort & "'"

Public Shared Function SafeSql(ByVal s As String) As String
Return s.Replace("'", "''")
End Function
Listing: Filtern aller potentiell gefährlichen Zeichen, insbesondere des einfachen Anführungszeichens, aus der Eingabe