it-swarm.com.de

Könnte Hashing die SQL-Injection verhindern?

Aus einer Laune heraus habe ich kürzlich beschlossen, die erste richtige Website, die ich erstellt habe, auf meinem lokalen Webserver zu veröffentlichen, den ich für die Entwicklung verwende. Ich dachte, es wäre eine großartige Umgebung, um SQL zur Injektion zu verwenden, da ich weiß, dass es Fehler gibt und die Site nur für meine persönliche Entwicklung gedacht war.

Um auf den Punkt zu kommen, war es nach ein paar Versuchen am weitesten, dass die Seite einen Fehler mit der Anweisung zurückgab. Ich habe versucht, in ein bestimmtes Testkonto zu gelangen, das ich eingerichtet habe (wenn das Ergebnis mehr als ein Konto zurückgibt, wird ein Fehler ausgegeben, sodass ich nicht damit gerechnet habe, jeden Benutzernamen auszuwählen, bei dem 1 = 1 funktioniert), aber jedes Mal, wenn ich einen bekam Antwort, als hätte ich ein normales, falsches Passwort eingegeben. Ich habe mir den Code PHP] angesehen und festgestellt, dass ich das Kennwort vor der Abfrage gehasht habe, sodass der Angriff gehasht wurde, bevor er Schaden anrichten konnte.

Da ich neu in der Web-Sicherheit insgesamt bin und ein Interesse an der Web-Entwicklung habe, habe ich mich gefragt, ob diese Methode der SQL-Injection -Vorbeugung Schwachstellen aufweist, da ich davon ausgehe, dass ich nichts durchdacht habe. Nur um das zu verdeutlichen, dies ist kein "Look, Leute, ich habe etwas Neues gefunden", da es in der Informationssicherheit viel hellere Funken gibt als ich selbst, die dies wahrscheinlich schon herausgefunden hätten, aber ich würde es gerne tun wissen, warum dies wahrscheinlich nicht als Sicherheitsmechanismus geeignet ist.

22
lewis

Das Hashing des Benutzerkennworts vor der Eingabe in die Abfrage ist also eine zufällige Sicherheitsfunktion, um die SQL-Injection zu verhindern. Dies kann jedoch nicht unbedingt mit allen Benutzereingaben geschehen. Wenn ich einen Kunden anhand seines Namens suche und eine Frage wie habe

Select * from Customer Where Name like '%userInput%'

Wenn ich userInput als Hash-Version von dem, was eingegeben wurde, festlegen würde, würde es nicht richtig funktionieren, selbst wenn Name auch in der Datenbank gehasht wurde, würde es nur für genaue Suchabfragen funktionieren. Wenn ich also einen Kunden mit dem Namen "Sue" hätte und eine Suche nach "sue" eingeben würde, würde das nicht funktionieren. Ich würde auch den Namen der Kunden nicht kennen, wenn meine Suche nicht genau übereinstimmt, was nicht praktikabel ist.

Die Art und Weise, wie Sie die SQL-Injection verhindern möchten, besteht darin, Ihre Abfragen nicht wie oben beschrieben durchzuführen. Sie möchten Eingaben in einer Abfrage verarbeiten und parametrisieren und dabei Dinge wie = s und andere Symbole entfernen, die im Kontext der Eingabe keinen Sinn ergeben . Eine gute Anleitung zum Verhindern der SQL-Injection finden Sie hier .

36
Ryan Kelso

Grundsätzlich ja, wenn Sie eine Hash-Eingabe (dargestellt im Hex- oder Base64-Format) vor der Übergabe an SQL erstellen, kann dies kein effektiver SQLi-Angriffsvektor mehr sein. Das gleiche gilt, wenn Sie die Eingabe parseInt. Diese unterstützen einfach nicht die Zeichen, die für ein nützliches SQLi benötigt werden. (nämlich aus der zitierten Zeichenfolge auszubrechen)

Diese Technik ist in der Praxis nur begrenzt anwendbar. d.h. es wäre nicht kompatibel mit einigen der berühmten SQL-Funktionen wie LIKE, <, >,
oder indizierte Gleichstellungssuchen (= und <> using index)

Als Randnotiz möchte ich darauf hinweisen, dass Passwort-Hashes sollte wirklich gesalzen werden . Wenn diese Kriterien in Ihrem Beispiel erfüllt wären, würden Sie wahrscheinlich keinen Hash mehr in die SQL WHERE -Klausel aufnehmen.

7
Bryan Field

Was Sie (versehentlich) tun, ist Teil der sogenannten "Bereinigung Ihrer Eingabe". Dies sind Schritte, die jede Anwendung unternehmen sollte, um Fehler (und damit Schwachstellen) zu reduzieren.

Eine App sollte zunächst sicherstellen, dass die Eingabe die Fähigkeit der App, Daten zu akzeptieren, nicht überlaufen kann. Dies kann bedeuten, dass die Eingabe in der Länge überprüft oder auf andere Weise übergroße Daten abgelehnt werden.

Als nächstes sollte die App die Eingabe nach Möglichkeit anhand einer Whitelist prüfen, um sicherzustellen, dass keine unerwünschten Eingaben in die Logik gelangen können. In einigen Fällen kann dies bedeuten, dass sichergestellt wird, dass die Eingabe nur gültige alphanumerische Zeichen enthält. Aber manchmal macht eine Whitelist für dieses bestimmte Eingabefeld keinen Sinn, dennoch muss der Entwickler die Injektion verhindern, sodass er eine schwarze Liste enthält. Die schwarze Liste bestätigt, dass die Eingabe keine Symbole enthält, von denen bekannt ist, dass sie die Injektion ermöglichen. Der Nachteil von Blacklists ist, dass sie nur vor dem schützen, was der Entwickler zu blockieren weiß. Ein Beispiel könnte eine schwarze Liste sein, die ein Anführungszeichen stoppt, um eine SQL-Injection zu verhindern. Der Entwickler erkennt jedoch möglicherweise nicht, wenn eine Eingabe über eine verschlüsselte URL erfolgt, dass ein% 27 zu einem Anführungszeichen wird.

Intern sollte der Antrag defensiv geschrieben werden, um verschiedene Formen der Injektion zu verhindern. Die Verwendung von parametrisiertem SQL (anstatt eine SQL-Abfrage mithilfe von Verkettung zu erstellen) hilft, die SQL-Injection zu verhindern. Aber viele andere Orte, an denen Benutzereingaben landen, können für verschiedene Arten der Injektion anfällig sein. Verzeichnispfade können beeinträchtigt werden, wenn ein Angreifer so etwas wie "..\..\..\..\..\..\windows\cmd.exe" XPath-Abfragen eingibt, um nicht autorisierte Daten zu manipulieren. Und JavaScript kann den gesamten Weg durch die Datenbank durchlaufen, um den Browser des Opfers zu manipulieren. Andere Verteidigungsformen umfassen das Nichtaufdecken interner Diagnosefehlermeldungen in der Ausgabe und die Protokollierung, um die Identifizierung potenzieller Angreifer zu erleichtern.

Was Ihre App getan hat, ist, zuerst die Eingabe an eine Hash-Routine zu übergeben, die den doppelten Effekt hat, die Daten zu bereinigen und ihre Länge zu begrenzen, bevor sie zum SQL-Schritt gelangen. Beachten Sie jedoch, dass die Eingabe in die Hash-Routine möglicherweise immer noch anfällig für einen Pufferüberlauf ist. Was passiert, wenn ein Angreifer ein Passwort von "aaaa[...repeated 1000 times...]aaaa_Evil_Injection_Here" Eingebt? Ihre App muss das noch erledigen.

1
John Deters

Wie viele andere Lernende verwirren Sie den Speicher und den Transport . Und um Letzteres zu schützen, verwöhnen Sie Ersteres absichtlich.

Sie müssen verstehen, dass SQL-Injection aus einem bestimmten Grund nicht als "Database Injection" bezeichnet wird. Sie müssen die Datenbank, den Speicher nicht schützen. Alles, was Sie schützen müssen, ist der Transport - die SQL-Abfrage. Während Ihr Speicher in der Lage sein sollte, speichern Sie die Daten wie sie sind, oder es wird überhaupt keinen Wert haben. Wenn Sie noch einen Beweis für diese Aussage benötigen,

  • es könnte verschiedene Kunden geben, die keine Ahnung von Ihrem selbst gebrauten "Schutz" haben.
  • es gibt nicht nur einen strengen Vergleich und nicht nur einen Vergleich: Es gibt eine Vielzahl von Aussagen, an denen Ihre Daten beteiligt sein könnten: Arithmetik, Teilstringsuche, verschiedene Konvertierungen, String-Manipulationen und Berechnungen aller Art
  • eine Datenbank wird nicht nur zum Speichern, sondern auch zum Bearbeiten Ihrer Daten verwendet. Versuchen Sie , Ihre Hash-Benutzernamen zu bestellen (- === -)
  • Schließlich müssen Sie manchmal die Daten aus einer Datenbank zurückdrucken .

Sie können also feststellen, dass jede Schutzmaßnahme, die die gespeicherten Daten in irgendeiner Weise verändert, einfach falsch ist. Und Ihre Idee ist einfach nicht gut durchdacht.

1

Hashing schützt die SQL-Injection des Kennwortfelds durch den Schritt, der seine Binärausgabe zurück in eine Zeichenfolge codiert.

Dieser Schutz ist normalerweise nutzlos, reicht jedoch aus, wenn die folgenden Annahmen zutreffen:

  • Ihre Anwendung verarbeitet nur Zeichenfolgen außer Benutzername und Kennwort.
  • Sie entfernen den Benutzernamen von ' und \ Figuren.

Wenn eines davon nicht zutrifft oder jemals in der Zukunft liegt, ist Hashing keine nützliche Verteidigung. Dadurch werden 99,9% der Webanwendungen eliminiert.

0
Joshua