1. Was ist ein SQL-Injection-Angriff?
Bei einem SQL-Injection-Angriff fügt ein Angreifer SQL-Befehle in das Eingabefeld eines Webformulars oder die Abfragezeichenfolge einer Seitenanforderung ein und verleitet so den Server zur Ausführung bösartiger SQL-Befehle. In einigen Formularen werden Benutzereingaben direkt zum Erstellen (oder Beeinflussen) dynamischer SQL-Befehle oder als Eingabeparameter für gespeicherte Prozeduren verwendet. Solche Formulare sind besonders anfällig für SQL-Injection-Angriffe. Gängige SQL-Injection-Angriffsprozesse sind wie folgt:
⑴ Eine ASP.NET-Webanwendung verfügt über eine Anmeldeseite. Diese Anmeldeseite steuert, ob der Benutzer die Berechtigung hat, auf die Anwendung zuzugreifen Passwort.
⑵ Der auf der Anmeldeseite eingegebene Inhalt wird direkt zum Erstellen dynamischer SQL-Befehle oder direkt als Parameter gespeicherter Prozeduren verwendet. Das Folgende ist ein Beispiel für eine ASP.NET-Anwendung, die eine Abfrage erstellt:
System.Text.StringBuilder query = new System.Text.StringBuilder(
"SELECT * from Users WHERE login = '")
.Append(txtLogin.Text).Append("' AND password='")
.Append(txtPassword.Text).Append("'");Nach dem Login kopieren
⑶ Der Angreifer gibt „' oder ‚1‘=‘1“ in den Benutzernamen und das Passwort ein Eingabefelder für Klasseninhalte.
⑷ Nachdem die vom Benutzer eingegebenen Inhalte an den Server übermittelt wurden, führt der Server den obigen ASP.NET-Code aus, um einen SQL-Befehl zur Abfrage des Benutzers zu erstellen Speziell, der letzte SQL-Befehl lautet :SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'.
⑸ Der Server führt eine Abfrage oder gespeicherte Prozedur aus, um die vom Benutzer eingegebenen Identitätsinformationen mit den auf dem Server gespeicherten Identitätsinformationen zu vergleichen.
⑹ Da der SQL-Befehl tatsächlich durch einen Injektionsangriff geändert wurde, kann die Identität des Benutzers nicht wirklich überprüft werden, sodass das System den Angreifer fälschlicherweise autorisiert.
Wenn ein Angreifer weiß, dass die Anwendung den im Formular eingegebenen Inhalt direkt für Abfragen zur Identitätsprüfung verwenden wird, wird er versuchen, einige spezielle SQL-Zeichenfolgen einzugeben, um die Abfrage zu manipulieren, ihre ursprüngliche Funktionalität zu ändern und das System auszutricksen in die Gewährung von Zugriffsrechten.
Je nach Systemumgebung ist auch der Schaden, den ein Angreifer anrichten kann, unterschiedlich, was hauptsächlich durch die Sicherheitsberechtigungen der Anwendung für den Zugriff auf die Datenbank bestimmt wird. Wenn das Benutzerkonto über Administrator- oder andere relativ fortgeschrittene Rechte verfügt, kann der Angreifer verschiedene Vorgänge an den Datenbanktabellen ausführen, die er ausführen möchte, darunter das Hinzufügen, Löschen oder Aktualisieren von Daten oder sogar das direkte Löschen der Tabelle.
2. Wie kann man es verhindern?
Glücklicherweise ist es nicht besonders schwierig, das Eindringen von SQL-Injection-Angriffen in ASP.NET-Anwendungen zu verhindern, solange Sie den gesamten Eingabeinhalt filtern, bevor Sie den Formulareingabeinhalt zum Erstellen des SQL-Befehls verwenden Es. Das Filtern von Eingaben kann auf verschiedene Arten erfolgen.
⑴ Zum dynamischen Erstellen von SQL-Abfragen können Sie die folgende Technologie verwenden:
Erstens: Ersetzen Sie einfache Anführungszeichen, dh ändern Sie alle einzelnen Anführungszeichen, die einzeln angezeigt werden, in zwei einfache Anführungszeichen, um dies zu verhindern Der Angreifer ändert die Bedeutung von SQL-Befehlen. Wenn wir uns das vorherige Beispiel noch einmal ansehen, wird offensichtlich „SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'“ erhalten das gleiche "SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'" unterschiedliche Ergebnisse.
Zweitens: Entfernen Sie alle Bindestriche in Benutzereingaben, um zu verhindern, dass Angreifer Abfragen wie „SELECT * from Users WHERE login = 'mas' -- AND password =''“ erstellen Da die Abfrage auskommentiert wurde und nicht mehr gültig ist, muss der Angreifer nur einen legitimen Benutzeranmeldenamen und nicht das Kennwort des Benutzers kennen, um erfolgreich Zugriff zu erhalten.
Drittens: Beschränken Sie die Berechtigungen des Datenbankkontos, das zum Ausführen von Abfragen verwendet wird. Verwenden Sie verschiedene Benutzerkonten, um Abfrage-, Einfüge-, Aktualisierungs- und Löschvorgänge durchzuführen. Durch die Isolierung der Vorgänge, die von verschiedenen Konten ausgeführt werden können, wird verhindert, dass der Ort, an dem ursprünglich der SELECT-Befehl ausgeführt wurde, für die Ausführung des INSERT-, UPDATE- oder DELETE-Befehls verwendet wird.
⑵ Verwenden Sie gespeicherte Prozeduren, um alle Abfragen auszuführen.
Die Art und Weise, wie SQL-Parameter übergeben werden, verhindert, dass Angreifer einfache Anführungszeichen und Bindestriche verwenden, um Angriffe durchzuführen. Darüber hinaus können Datenbankberechtigungen so eingeschränkt werden, dass nur die Ausführung bestimmter gespeicherter Prozeduren möglich ist. Alle Benutzereingaben müssen dem Sicherheitskontext der aufgerufenen gespeicherten Prozedur entsprechen, sodass Injektionsangriffe nur schwer möglich sind.
⑶ Begrenzen Sie die Länge der Formular- oder Abfragezeichenfolgeneingabe.
Wenn der Anmeldename des Benutzers höchstens 10 Zeichen lang ist, dürfen nicht mehr als 10 Zeichen in das Formular eingegeben werden. Dies erhöht die Schwierigkeit für Angreifer erheblich, schädlichen Code in SQL-Befehle einzufügen.
⑷ Überprüfen Sie die Rechtmäßigkeit der Benutzereingaben und stellen Sie sicher, dass der Eingabeinhalt nur legale Daten enthält.
Die Datenprüfung sollte sowohl auf der Client- als auch auf der Serverseite durchgeführt werden – die serverseitige Validierung wird durchgeführt, um die fragile Sicherheit des clientseitigen Validierungsmechanismus auszugleichen.
Auf der Clientseite ist es für einen Angreifer durchaus möglich, an den Quellcode der Webseite zu gelangen, das Skript zur Überprüfung der Rechtmäßigkeit zu ändern (oder das Skript direkt zu löschen) und dann den illegalen Inhalt über das an den Server zu übermitteln modifizierte Form. Daher besteht die einzige Möglichkeit, sicherzustellen, dass der Verifizierungsvorgang tatsächlich durchgeführt wurde, darin, die Verifizierung auch auf der Serverseite durchzuführen. Sie können viele der integrierten Validierungsobjekte verwenden, z. B. RegularExpressionValidator, der automatisch clientseitige Skripts zur Validierung generieren kann, und natürlich können Sie auch serverseitige Methodenaufrufe einfügen. Wenn Sie kein vorgefertigtes Validierungsobjekt finden, können Sie über CustomValidator selbst eines erstellen.
⑸ Verschlüsseln und speichern Sie den Anmeldenamen, das Passwort und andere Daten des Benutzers.
Verschlüsseln Sie die vom Benutzer eingegebenen Daten und vergleichen Sie sie dann mit den in der Datenbank gespeicherten Daten. Dies entspricht einer „Sterilisierung“ der vom Benutzer eingegebenen Daten Auswirkungen auf die Datenbankbedeutung und verhindern so, dass Angreifer SQL-Befehle einschleusen. Die System.Web.Security.FormsAuthentication-Klasse verfügt über eine HashPasswordForStoringInConfigFile, die sich sehr gut zum Bereinigen von Eingabedaten eignet.
⑹ Überprüfen Sie die Anzahl der Datensätze, die von der Abfrage zurückgegeben werden, die Daten extrahiert.
Wenn das Programm nur die Rückgabe eines Datensatzes anfordert, der tatsächlich zurückgegebene Datensatz jedoch mehr als eine Zeile umfasst, wird dies als Fehler behandelt.
Das Obige zeigt, wie ASP.NET SQL-Injection-Angriffe verhindert. Ich hoffe, es wird für das Lernen aller hilfreich sein.
Weitere Artikel darüber, wie ASP.NET SQL-Injection-Angriffe verhindern kann, finden Sie auf der chinesischen PHP-Website!
