SQL Injection

Geschrieben von: Christoph Wille
Kategorie: Sicherheit

Ein wie immer brillanter Michael Howard (Program Manager, Secure Windows Initiative, Microsoft Corporation) hat auf der Professional Developers Conference (PDC) 2001 in Los Angeles zwei Vorträge über Sicherheit gehalten - einen über Windows-, den anderen über Websicherheit. Der letztere hat mich davon überzeugt, wie wichtig es ist, Programmierer über das Sicherheitsrisiko #1 für ASP Datenbankapplikationen zu informieren: SQL Injection.

Was ist SQL Injection? Am besten erklärt sich das anhand eines Augen-öffnenden Beispiels, und ich habe dazu ein beliebtes Formular gewählt: das Login Formular.

Der Code für das Formular ist simpel genug um ihn auszulassen - interessant ist nur der Code, der den Login durchführt:

<% @ Language=VBScript %>
<%
strConn = "Provider=SQLOLEDB;Data Source=webdevsrv01;" & _
	  "Initial Catalog=Demo;User Id=sa;Password="

bValidationFailed = False

If Request.ServerVariables("CONTENT_LENGTH") > 0 Then
  strUsername = Trim(Request.Form("UName"))
  strPassword = Trim(Request.Form("UPwd"))
  Set rs = Server.CreateObject("ADODB.Recordset")
  rs.Open "select count(*) from Users where UserName='" & strUsername &_
        "' AND UserPassword='" & strPassword & "'" , strConn
  If (rs.Fields(0).Value > 0) Then 
    Response.Redirect "supa.asp"
    Response.End
  Else
    bValidationFailed = True
  End If
End If
%>

Sieht doch ganz normal aus, oder? Sehen wir uns an, wie der SQL String aussieht, wenn sich der Administrator mit admin / admin einloggt:

select count(*) from users where UserName='admin' AND UserPassword='admin'

Der Administrator fällt also definitiv unter die Kategorie "Gute Menschen" - was aber würde ein Cracker versuchen? Wie wär's mit folgender Benutzername und Passwort Kombination: ' OR '1'='1 und ' OR '1'='1. Der SQL String sieht dann so aus:

select count(*) from users where UserName='' OR '1'='1' AND 
         UserPassword='' OR '1'='1'

Oopsie! Tja, damit sind wir schon auf der gesicherten Site gelandet - und nur weil wir die Benutzereingaben nicht validiert haben.

Aber es geht noch mehr... wie wär's mit Benutzername ' DELETE Users --?

select count(*) from users where UserName='' DELETE Users --' AND 
         UserPassword=''

Oopsie! Da hab' ich doch gerade sämtliche Benutzeraccounts aus der Tabelle gelöscht! Die zwei Dashes (-) leiten einen Kommentar ein, deswegen gab's mit dem nach AND folgenden String keinen Fehler.

Kein Problem, als Cracker kann man das Problem wieder beseitigen... wie wär's hiermit als Benutzername: ' insert into Users values('got','you') --"? Guess what - damit kann man sich einen Account anlegen!

select count(*) from users where UserName='' insert into Users values('got','you') --' AND 
         UserPassword=''

Das ist der Fahnenstange Ende leider noch nicht. Warum? Folgende weitere Dummheit im Sourcecode:

<% @ Language=VBScript %>
<%
strConn = "Provider=SQLOLEDB;Data Source=webdevsrv01;" & _
	  "Initial Catalog=Demo;User Id=sa;Password="
...

Wir sind der Faulheit halber mit dem sa Account eingeloggt. Nun, da würde sich doch folgendes ganz hervorragend anbieten: ' EXEC master..xp_cmdshell 'dir *.* > c:\listing.txt' --

select count(*) from users where UserName='' EXEC master..xp_cmdshell 'dir *.* > c:\listing.txt' --' AND 
         UserPassword=''

Das ist ein höfliches Beispiel, das "nur" das Root des Systemlaufwerks auflistet. Mit Hilfe des net Kommandos könnten wir uns aber einen User Account in der Administratorengruppe anlegen. Den Code soll sich aber jeder selber basteln.

Mit diesen Beispielen hoffe ich demonstriert zu haben, was SQL Injection ist - das Einfügen von beliebigen SQL Strings in Formulare, die dann am Server ausgeführt werden. Und warum passiert das? Weil die Formulare dem Input der Benutzer vertrauen, und ihn nicht entsprechend validieren. Generell sollte Michael Howard's Regel gelten: All input is evil, until proven otherwise!. Somit ist die Gegenmaßnahme klar: validieren, validieren, validieren.

Schlußbemerkung

Im nächsten Artikel beschäftige ich mich mit einigen Gegenmaßnahmen, die neben validieren, validieren, validieren auch einige RegEx und ADO Ansätze beinhalten.

Verwandte Artikel

Benutzerverwaltung leicht gemacht: Teil 1
Der Microsoft Baseline Security Analyzer (MBSA) 1.0
Eigene Tags - User Input einfach und sicher
Ein einfacher Eventkalender für Projektteams
Formularbasierte Authentifizierung in fünf Minuten
Gegengifte für SQL Injection
Performancemessungen in .NET
Stored Procedures einfach erstellt
Verhinderung von SQL Injection Marke .NET
Vorsicht Falle: Dateien, die keine sind

Wenn Sie jetzt Fragen haben...

Wenn Sie Fragen rund um die in diesem Artikel vorgestellte Technologie haben, dann schauen Sie einfach bei uns in den Community Foren der deutschen .NET Community vorbei. Die Teilnehmer helfen Ihnen gerne, wenn Sie sich zur im Artikel vorgestellten Technologie weiterbilden möchten.

Haben Sie Fragen die sich direkt auf den Inhalt des Artikels beziehen, dann schreiben Sie dem Autor! Unsere Autoren freuen sich über Feedback zu ihren Artikeln. Ein einfacher Klick auf die Autor kontaktieren Schaltfläche (weiter unten) und schon haben Sie ein für diesen Artikel personalisiertes Anfrageformular.

Und zu guter Letzt möchten wir Sie bitten, den Artikel zu bewerten. Damit helfen Sie uns, die Qualität der Artikel zu verbessern - und anderen Lesern bei der Auswahl der Artikel, die sie lesen sollten.