Ich habe einige versuchte SQL-Injection-Angriffe auf einer meiner Websites gesehen. Es kommt in Form einer Abfragezeichenfolge, die das "Cast" -Schlüsselwort und eine Reihe von Hexadezimalzeichen enthält, die, wenn sie "dekodiert" werden, eine Injektion von Banneranzeigen in die DB sind.
Meine Lösung besteht darin, die vollständige URL (und die Parameter) zu scannen und nach dem Vorhandensein von "cast (0x") zu suchen und nach einer statischen Seite zu suchen.
Wie überprüfen Sie Ihre URLs auf SQL Injection-Angriffe?
Ich denke, es hängt davon ab, auf welcher Ebene Sie SQL Injection überprüfen / verhindern wollen.
Auf der obersten Ebene können Sie URLScan oder einige Apache Mods / Filter (jemand hilft mir hier) verwenden, um die eingehenden URLs auf den Webserver selbst zu überprüfen und Anfragen, die einem bestimmten Muster entsprechen, sofort zu löschen / ignorieren.
>Auf UI-Ebene können Sie den Eingabefeldern, die Sie einem Benutzer geben, einige Validatoren zuweisen und maximale Längen für diese Felder festlegen. Sie können auch bestimmte Werte / Muster nach Bedarf auflisten.
Auf Codeebene können Sie, wie oben erwähnt, parametrisierte Abfragen verwenden, um sicherzustellen, dass String-Eingaben als reine String-Eingaben eingehen und nicht versuchen, T-SQL- / PL-SQL-Befehle auszuführen.
Sie können es auf mehreren Ebenen tun, und die meisten meiner Sachen haben Datum die zweiten beiden Probleme, und ich arbeite mit unseren Server Admins, um die Top-Layer-Sachen an Ort und Stelle zu bekommen.
Stimmt das eher mit dem, was Sie wissen wollen?
Ich nicht.
Stattdessen verwende ich parametrisierte SQL-Abfragen und verlasse mich auf die Datenbank, um meine Eingabe zu bereinigen.
Ich weiß, das ist ein neuartiges Konzept für PHP-Entwickler und MySQL-Benutzer, aber Leute, die echte Datenbanken verwenden, machen das schon seit Jahren so.
Zum Beispiel (mit C #)
%Vor%Ich nicht. Es ist der Zweck der Datenbankzugriffsebene, sie zu verhindern, nicht die URL-Zuordnungsebene, um sie vorherzusagen. Verwenden Sie vorbereitete Anweisungen oder parametrisierte Abfragen und machen Sie sich keine Sorgen mehr über SQL-Injection.
Es gibt verschiedene Möglichkeiten, einen SQL Injection-Angriff entweder über eine Abfragezeichenfolge oder ein Formularfeld auszuführen. Das Beste, was Sie tun müssen, ist, Ihre Eingaben zu bereinigen und sicherzustellen, dass Sie nur gültige Daten akzeptieren, anstatt zu versuchen, Dinge, die möglicherweise schlecht sind, zu verteidigen und zu blockieren.
Was ich nicht verstehe ist, wie die Beendigung der Anfrage, sobald eine SQL-Injection in der URL erkannt wird, nicht Teil einer Verteidigung sein soll?
(Ich behaupte nicht, dass dies die gesamte Lösung ist - nur ein Teil der Verteidigung.)
cast(0x , aber was, wenn der Angreifer CAST (0x verwendet? Sie könnten eine Art Pre-Parser für die Abfrage-Strings implementieren, aber es müsste einen nicht-trivialen Teil des SQL analysieren. SQL ist bekanntlich schwer zu parsen. SELECT , UPDATE usw. verwenden und muss wissen, welche Datenbank verwendet wird. Danke für die Antworten und Links. Übrigens benutzte ich bereits parametrisierte Abfragen und deshalb war der Angriff ein "versuchter" Angriff und kein erfolgreicher Angriff. Ich stimme Ihren Vorschlägen zur Parametrisierung von Abfragen voll und ganz zu.
Der MSDN-Post-Link erwähnt als Teil des Ansatzes, der Teil meiner derzeitigen Strategie ist, die "Beschränkung der Eingabe". Es erwähnt auch, dass ein Nachteil dieses Ansatzes darin besteht, dass Sie einige der gefährlichen Eingaben übersehen können.
Die bisher vorgeschlagenen Lösungen sind gültig, wichtig und Teil der Verteidigung gegen SQL-Injection-Angriffe. Die Frage nach "Eingrenzen der Eingabe" bleibt offen: Was können Sie sonst in der URL als erste Verteidigungslinie suchen?
Was können Sie sonst in der URL als erste Verteidigungslinie suchen?
Nichts. Beim Scannen von URLs auf gefährliche Zeichenfolgen kann keine Abwehr gefunden werden.
Nichts. Beim Scannen von URLs auf gefährliche Zeichenfolgen kann keine Abwehr gefunden werden.
@John - können Sie das ausarbeiten?
Was ich nicht verstehe ist, wie die Beendigung der Anfrage, sobald eine SQL-Injection in der URL erkannt wird, nicht Teil einer Verteidigung sein soll?
(Ich behaupte nicht, dass dies die gesamte Lösung ist - nur ein Teil der Verteidigung.)
Tags und Links sql sql-server