Warum IIS? - Folge 13: „SQL Injections Abwehren zum Nulltarif“
Wissen Sie immer wie gut die Code-Qualität der Websites auf Ihrem Server ist? Hmmm...
Als Administrator weiß man vieles, aber vielleicht eben nicht was der gutgläubige Entwickler zusammenprogrammiert hat, und das Ganze läuft dann auf Ihrem Webserver, arrggghhh.
Websites die mittels Query Strings https://..../ /Products.aspx?ProduktID=1 Informationen aus der DB holen. Haben Sie so etwas?
Zur Gefahr wird das, wenn Eingaben ungeprüft übernommen (weil "wird schon passen oder Prüfung zu mühsam") und daraus DB Abfragen mittels String-Verkettung zusammengebastelt werden.
Gefahr, weil dadurch ein Angreifer DB Abfragen erweitern kann um z.B. Preise in der Produkt-Tabelle zu verändern, andere Tabellen abfragen oder gleich die ganze Tabelle ins Nirwana schickt kann,...
Was ist falsch an folgendem Code?
Was würde passieren wenn ich die Seite mit:
aufrufen würde?
Richtig, das Produkt würde deutlich billiger werden ;-) Warum?
Weil das zusammengesetzte DB Kommando so aussehen würde:
Um das Problem zu beheben wäre dieser Code schon deutlich besser:
string commandText = "select * from Produkte where ProduktID = @ID ";
cmd = new SqlCommand(commandText, conn);
cmd.Parameters.AddWithValue("@ID", queryStrings["ProduktID"]);
conn.Open();
...
Parametrisiert: Somit ist sichergestellt, dass das was vom User kommt (der QueryString) für den SQL immer ein Parameter ist und unser böserweise angehängter T-SQL Befehl wird nicht mehr ausgeführt!
Auch dieser Code ließe sich noch verbessern, z.B. um die Länge der Zeichenkette zu begrenzen, oder nur Zahlen zu akzeptiert nicht aber Sonderzeichen. (siehe SQL Injection).
"Every input is evil!" - Wie kann man sich dagegen schützen?
In der Entwicklungsphase:
Ideal wäre natürlich wenn schlechter Code gar nicht erst entstünde - helfen kann da z.B. schon das Entwicklerwerkzeug. Die statische Codeanalyse von Visual Studio z.B. erzeugt bei obigem Beispiel folgende Warnung (siehe Hunting SQL Injection Bugs):
Alternativ kann man Websites mittels Test-Werkzeugen (z.B. Acunetix Web Vulnerability Scanner, WebInspect, Absinthe) automatisiert scannen und etwaig gefundene SQL Injection Löcher anschließend stopfen.
In der Betriebsphase:
Ja was tun, wenn die Seiten schon live sind und man nicht mit der Unterstützung der Entwickler rechnen kann ("weil ist weg" – "oder wer war das überhaupt")?
Schadensbegrenzung ist hier die Devise, d.h. wenn sich das eigentliche Problem (schlechter Code) nicht gleich lösen / finden lässt, dann sollte man zumindest versuchen die Angriffsfläche zu minimieren.
Helfen können dabei Filter wie z.B. den IIS Request Filter zu verwenden um böswillige Anfragen gar nicht erst auf schwache Websites zu lassen.
Aber: Jeder Versuch auf Basis von Regeln SQL-Injektion Versuche zu vereiteln kann keinen 100%igen Schutz bieten.
Allerdings erhöht es die Einstiegshürde und hat gute Chancen den Hobby-Hacker auszusperren. Außerdem kriegen Sie mit wenn jemand sich an Ihren Seiten zu schaffen macht: Achten Sie auf 404.19 Fehler in Ihrer Web-Logdatei.
Request Filtering kostet nichts und tut auch nicht weh. Mit aktivierten Filtering und einer Regel:
bekommen wir auf unsere http Anfrage von oben folgende Meldung vom Server:
Vor dem Filtering war hier noch unsere Website zu sehen - mit aktiviertem Filtering zeigt die Fehlermeldung dass unsere Regel gegriffen hat, der Zugriff auf die Seite ist versperrt und der Schaden ist verhindert.
In der Weblog-Datei wird so ein Zugriff mit http Status 404 Substatus 19 geloggt, sodass Regelverstöße nicht unentdeckt bleiben.
Beispiele für Request Filtering Regeln findet man z.B. bei Request Filtering Rules
Anmerkung: Der IIS Request Filter oder die Alternative URLScan filtern auf Basis der URL, d.h. Eingaben in Formularfelder welche im message body per http POST an den Server geschickt können damit nicht gefiltert werden!
Fazit:
Sicherheitslöcher gehören im Code gefixt!
Allerdings bekommt der Webserver-Admin mit dem Request Filter schon ein gutes Schmerzmittel in seinen Werkzeugkasten.
Links:
Filtering for SQL Injection on IIS 7 and later