Wie kann ich SQL-Injection-Angriffe vermeiden?

Question

Gestern sprach ich mit einem Entwickler, und er erwähnte etwas über die Einschränkung der Einfügungen in Datenbankfelder, z.B. Strings wie -- (minus minus).

Was ich weiß, ist, dass es ein guter Ansatz ist, HTML-Zeichen wie < , > usw. Nicht -- . Ist das wahr? Muss ich mir Sorgen machen über -- , ++ ? Handelt es sich eher um einen Mythos oder um altes Zeug?

---

アップデート

Vielen Dank für all die Antworten, es ist leicht zu verstehen, da ich noch ziemlich neu in diesem Bereich bin. Nun, um genauer zu sein in diesem Fall unsere Diskussion war über und C# ASP.NET MVC-Website, die wir entwickeln, so gibt es eine komplexe ein Konto eröffnen Form dort mit wichtigen Informationen, so bin ich nicht sicher, ob MVC mit Linq, um die Schnittstelle mit Datenbank bereits mit dieser Art von Schutz kommt oder nicht. Wenn also jemand einige Hinweise dazu geben könnte, wäre das großartig. Nochmals vielen Dank

Answer 1

Die richtige Methode zur Vermeidung von SQL-Injection-Angriffen besteht NICHT darin, bestimmte problematische Zeichen einfach zu verbieten, sondern vielmehr darin, parametrisiertes SQL zu verwenden. Kurz gesagt, parametrisiertes SQL verhindert, dass die Datenbank rohe Benutzereingaben als Teil des SQL-Befehls ausführt, so dass Benutzereingaben wie "drop table" nicht ausgeführt werden können. Das bloße Escapen von Zeichen verhindert nicht alle Formen von SQL-Injection-Angriffen, und der Ausschluss bestimmter Wörter wie "Drop" funktioniert nicht in allen Fällen; es kann bestimmte Felder geben, in denen "Drop" ein durchaus zulässiger Teil der Dateneingabe ist.

Einige gute Artikel zum Thema paramaterisiertes SQL finden Sie hier:

https://blog.codinghorror.com/give-me-parameterized-sql-or-give-me-death/

http://www.codeproject.com/KB/database/ParameterizingAdHocSQL.aspx

Da Sie nun erwähnt haben, dass Sie mit ASP.net arbeiten, kann ich Ihnen einige Links geben, die sich speziell mit SQL Injection in ASP.

https://dzone.com/articles/aspnet-preventing-sql-injectio https://www.c-sharpcorner.com/UploadFile/75a48f/how-sql-injection-can-be-possible-in-asp-net-websites/

Hier finden Sie einen allgemeineren Artikel über die Verbesserung der Sicherheit Ihres ASP: http://www.codeproject.com/KB/web-security/Securing_ASP_NET_Apps.aspx

Und natürlich der MSDN-Artikel über SQL-Injection: http://msdn.microsoft.com/en-us/library/ms998271.aspx

Answer 2

SQL-Injektion ist ein hohes Sicherheitsrisiko für die meisten Websites, die es Nutzern erlauben, Parameter in eine Anweisung einzubauen, die in einer Datenbank ausgeführt wird.

Ein einfaches Beispiel wäre:

Eingabefeld "Name: _________

"SELECT * FROM tblCustomer WHERE Name = '" + nameInputField + "'"

Wenn ich also "Bob" eingebe, erhalten wir

"SELECT * FROM tblCustomer WHERE Name = 'Bob'"

Wenn ich jedoch "'; DROP TABLE tblCustomer" eingebe, erhalten wir das etwas unheimlichere Ergebnis

"SELECT * FROM tblCustomer WHERE Name = ''; DROP TABLE tblCustomer"

Es gibt viele Möglichkeiten, diese Probleme zu vermeiden, und viele davon sind in der von Ihnen verwendeten Sprache eingebaut - anstatt also an all die fragwürdigen Möglichkeiten ";", "--", "/*" usw. zu denken, versuchen Sie, etwas zu verwenden, das bereits existiert.

Sagen Sie uns, welche Sprache Sie verwenden, und ich bin sicher, wir können Ihnen sagen, wie Sie diese Angriffe vermeiden können.

Answer 3

Er sprach über SQL-Einschleusung Angriffe, wie es in seinen Ausführungen richtig heißt.

Das Problem liegt nicht darin, dass solche Daten in der Datenbank vorhanden sind, sondern darin, dass die Eingabedaten direkt an die Datenbank übergeben werden, ohne dass sie bereinigt werden.

Wenn jemand ohne Bereinigung eine Zeichenkette einreicht, die mit einem ; können sie dann mit allem, was sie wollen, folgen ( select * from sys.objects zum Beispiel) oder etwas Bösartiges, wie das Löschen einiger Tabellen.

Es ist schwierig, sich vollständig davor zu schützen, aber wenn Sie eine gute DB-Bibliothek in Ihrem Code verwenden und bekannte Praktiken befolgen, wie z. B. die Verwendung von paremeterisierten Abfragen, begrenzen Sie den möglichen Schaden.

Speichern Sie so viele -- in Ihre Datenbank ein, wie Sie wollen, aber geben Sie das nicht an Ihre Datenbank weiter, ohne einen Bereinigungsprozess zu durchlaufen (hier ist eine gute DB-Bibliothek entscheidend - sie sollte Anführungszeichen und andere potenziell schädliche Eingaben bereinigen).

Answer 4

Es ist nichts "Gefährliches" daran, eine Zeichenkette einzufügen, die -- in einer Datenbank.

Es ist gefährlich, ein alles in einer Datenbanktabelle, die direkt von einer Benutzereingabe stammt, ohne sie zu verarbeiten, da man sich sonst der Gefahr aussetzt SQL-Injection-Angriffe . Beispiel: Ein Programmierer lässt den Benutzer seinen Namen in ein Feld eingeben, und der Benutzer tippt:

Joe '); drop table users; commit transaction; --

und der Programmierer gibt das dann in seine MySQL-Datenbank ein, etwa so:

conn.execute("insert into users (username) values ('" + userInput + "')");

Boom Der Benutzer hat die Benutzertabelle gelöscht (vorausgesetzt, der Datenbank-Login hatte die Rechte dazu, was er nicht haben sollte - aber das ist ein anderes Thema), weil der Programmierer nicht sichergestellt hat, dass die Zeichenkette des Benutzers korrekt escaped wurde, und so wurde sie direkt an die DB-Engine gesendet und der Angreifer hat gut lachen :-)

Verwenden Sie die von Ihrer Umgebung bereitgestellten Werkzeuge, um sicherzustellen, dass Zeichenketten korrekt escaped werden. JDBC verwendet zum Beispiel die PreparedStatement Klasse für diesen Zweck. Die meisten Umgebungen haben etwas Ähnliches.

Answer 5

Verwenden Sie parametrisierte Abfragen. Diese Abfragen stellen die Variablen als Platzhalter in der SQL dar, z. B. select * from person where name = ? . Nachdem Sie die SQL-Abfrage erstellt haben, legen Sie die Parameterwerte in der Abfrage fest. Durch parametrisierte Abfragen wird sichergestellt, dass das, was anstelle des Platzhalters eingegeben wurde, nicht als Teil der SQL-Anweisung betrachtet wird.

Siehe Der Artikel von Jeff Atwood für einen guten Überblick über parametrisierte Abfragen.