Nein. Das Entfernen von Leerzeichen würde die SQL-Injection nicht verhindern, da es viele andere Möglichkeiten gibt, den Parser dazu zu bringen, Ihre Eingabe zu verarbeiten. Schauen wir uns ein Beispiel an. Stellen Sie sich vor, Sie hätten eine URL, bei der die vom Benutzer eingegebene Eingabe in einer Abfrage unsicher verwendet wurde:

http: //example/index.php? Id = 1 => SELECT * von Seite mit id = 1

In Ihrem Beispiel würde der Angreifer Leerzeichen verwenden:

http: //example/index.php? id = 1% 20oder% 201 = 1 => SELECT * von Seite mit id = 1 oder 1 = 1 .

Durch Entfernen der Leerzeichen wird die Injektion in eine Zeichenfolge reduziert.

Stellen wir uns nun vor, der Angreifer hat eine andere Form von Leerzeichen verwendet, z. B. Tabulatoren:

http: //example/index.php? id = 1% 09or% 091 = 1 => SELECT * von Seite mit id = 1 oder 1 = 1 .

Das Entfernen der Leerzeichen würde weiterhin die Injektion ermöglichen.

Abhängig von der verwendeten Technologie könnte der Angreifer die Leerzeichen durch / ** / % 00 % 09 % 0a % 0d oder eine beliebige Anzahl von Unicodes, die eine Tokenisierung durch den SQL-Parser verursachen. Während das referenzierte Beispiel mehr als nur Leerzeichen entfernt hat, nutzt das oben genannte Beispiel SQL-Kommentare, um die Tokenisierung zu verursachen, bei der es sich nicht um Leerzeichen handelt. Sie wären immer noch anfällig.

Die einzige zuverlässige Möglichkeit, die SQL-Injection zu verhindern, ist die Verwendung parametrisierter Abfragen.

Wir sind im Jahr 2016! SQL-Injections gehören der Vergangenheit an, sofern Sie keinen unsicheren Code verwenden.

Unabhängig davon, welche Sprache Sie verwenden, verwenden Sie vorbereitete Anweisungen oder eine andere Art der Datenbindung, wenn Sie SQL-Injektionen und alle verhindern möchten.

Vorbereitete Anweisungen trennen die Abfrage von den Daten, sodass die Daten die Abfrage nicht beeinflussen können.

Um Ihre Frage direkt zu beantworten, würde das Entfernen von Leerzeichen die SQL-Injektionen reduzieren (bei Verwendung veralteter Daten) Code und Bibliotheken), würde aber Ihren Eingabetext sicherlich einschränken (keine Leerzeichen).

Es würde das Problem begrenzen, aber nicht beseitigen. Stellen Sie sich folgende Situation vor:

  $ un = str_replace ("", "", $ _POST ["Benutzername"]); $ pw = Hash ($ _ POST ["Passwort"]; $ sql = "SELECT * FROM users WHERE Benutzername = '$ un' AND password = '$ pw'";  

Nehmen wir an, ich poste den Benutzernamen admin '- Das würde mich als Administrator anmelden, ohne ein einziges Leerzeichen zu verwenden.

Wie wireghoul hervorhebt, müssten Sie auch andere leere Zeichen wie tab entfernen. Aber als Julie Pelletier weist darauf hin, dass Sie nur vorbereitete Anweisungen verwenden. Der Versuch, clevere Schemata zu entwickeln, um SQLi zu stoppen, ohne dass dies ein unterhaltsames Spiel ist, bietet Ihnen möglicherweise nie die Sicherheit, die vorbereitete Anweisungen bieten nur eine Ablenkung.

Nein . Angenommen, Sie haben dies als SQL:

  "Wählen Sie * aus Personen aus, bei denen last_name = '" + Nachname + "'"  

Wenn ich Folgendes eingebe: 'OR (1 = 1) OR'a' = ' in die Eingabe, in die es umgewandelt wird:

  Wählen Sie * aus Personen aus, bei denen last_name =' 'OR (1 = 1) OR'a '=' ' 

Wird (mindestens) in Oracle und MySQL ausgeführt und gibt alle Zeilen aus der Tabelle zurück.

Wenn Sie jedoch diese Suchzeichenfolge verwendet haben

update aTable set someColumn = 'JackedUpValue', wobei someColumn die in dieser Frage gezeigte Operation ausführt, würde dies nicht der Fall sein Sie erhalten

updateaTablesetsomeColumn = 'JackedUpValue'wheresomeColumnlike , die nicht ausgeführt werden sollten, oder?

Wie andere darauf hingewiesen haben, gibt es andere Möglichkeiten Whitespace in verschiedene SQL-Datenbankimplementierungen einbinden, die Sie berücksichtigen müssten, z. B. Registerkarten und \ n (Zeilenumbruch). Fast jedes Datenbankmodul würde gerne Folgendes akzeptieren:

  updateaTablesetsomeColumn = 'JackedUpValue'  

Es kann verschiedene Unicode-Zeichen geben, die aufgrund der Lokalisierungseinstellungen in verschiedenen als Leerzeichen fungieren Datenbanken, aber Sie müssten sich wirklich mit Implementierungsdetails befassen, um das herauszufinden. Es gibt wirklich keinen Grund, all diese Randfälle für das Ersetzen von Zeichenfolgen abzudecken, anstatt nur parametrisierte Abfragen zu verwenden.

Hier ist eine Idee. Datenbankserver nehmen die eingehende SQL-Abfrage und führen sie über einen Parser aus, was zu einem Analysebaum führt. Dann verwandeln sie den Baum in einen Plan und führen den Plan aus.

Das Wesentliche bei der Injektion ist, dass der Parser einen Baum erzeugt, der sich von dem vom Programmierer beabsichtigten unterscheidet.

Also das Update ist es, ungewöhnliche Analysebäume erkennen zu können. Gehen Sie nach dem Parsen über den Baum und erstellen Sie eine Zeichenfolge in kanonischer Form abzüglich der Datenwerte. Berechnen Sie einen SHA-Hash der Zeichenfolge. Führen Sie eine Tabelle mit bekannten Hashes für den Anwendungs- / Datenbankbenutzer. Warnen oder abbrechen, wenn der Server einen unbekannten Hash sieht.

Offensichtlich liegt ein Startproblem vor. Der Programmierer müsste also die Anwendung in einem Testmodus ausführen, die Hashes nach ausführlichen Tests extrahieren und den Server beim Start der Anwendung mit den Hashes laden. Aktivieren Sie dann "Abort-on-New-Hash" und es sollte kein SQL-Inject mehr möglich sein.