Vertrauen Sie allen authentifizierten Benutzern vollständig? Einschließlich, dass ihre Konten nicht von Angreifern kompromittiert werden? Es ist schlecht, wenn ein Angreifer Zugriff auf ein Konto erhält, aber weitaus schlimmer, wenn er dies nutzen kann, um den Rest Ihrer Datenbank zu stehlen.

Für Ihren zweiten Punkt wäre das von Ihnen verwendete Beispiel nicht anfällig . Achten Sie jedoch auf weitere Grenzfälle wie

  $ query = "SELECT * FROM tableName WHERE secret = '". Dbquery ("SELECT secret FROM otherTable WHERE id = 3"). "' ";  

Wenn es möglich war, eine Nutzlast in otherTable in der Spalte secret einzufügen, um sie mit id aufzuzeichnen Code> 3, dies wäre anfällig für SQLi zweiter Ordnung, selbst wenn die Einfügeroutine vorbereitete Anweisungen verwendet.

Gemäß den Kommentaren:

  SELECT * FROM tableName WHERE secret = (SELECT secret FROM otherTable WHERE id = 3)  

wird in SQL ausgeführt, ist also kein Problem. Das Problem tritt auf, wenn Daten aus der Datenbank auf der Anwendungsebene als vertrauenswürdig betrachtet und in späteren Abfragen verwendet werden.

Sie sagen: "Ich glaube, ich verstehe die Grundlagen der SQL-Injection." aber der Rest der Frage impliziert, dass Sie vielleicht noch etwas Verwirrung haben. In beiden Fällen ist dies ein wichtiges Thema, und viele Menschen sind weiterhin verwirrt über das Problem und die Lösung.

Ich weiß auch, dass die Verwendung vorbereiteter Anweisungen mit PHP-Dateien der beste Weg ist, um SQL-Injection zu verhindern.

Die Verwendung vorbereiteter Anweisungen ist eine notwendige, aber nicht ausreichende Bedingung, um vor SQL Injection (SQLi) zu schützen. Um zu verstehen, warum, ist es wichtig, die Ursache von SQL Injection-Schwachstellen zu verstehen. Hier sind die Ursachen:

1. Verketten von SQL-Anweisungen aus Benutzer- / Client-Eingaben.
ol>

Das war's. Wenn Sie Eingaben vom Benutzer in eine SQL-Anweisung einfügen, die Sie dann in der Datenbank kompilieren, sind Sie möglicherweise SQLi-Schwachstellen ausgesetzt (und sind dies wahrscheinlich auch). Wenn Sie dies tun und eine vorbereitete Anweisung verwenden, haben Sie nichts gelöst. Sie sind immer noch verwundbar.

Warum werden vorbereitete Anweisungen immer als Antwort angegeben? Wenn wir das SQL nicht mit der Eingabe verketten können, bedeutet dies, dass unser SQL mehr oder weniger fest codiert sein muss. Aber was ist, wenn Sie die Benutzerinformationen für denjenigen zurückziehen möchten, der sich gerade angemeldet hat? Wir können nicht jedes Mal eine neue SQL-Anweisung schreiben, wenn wir einen neuen Benutzer haben.

Vorbereitete Anweisungen

Was vorbereitete Anweisungen zur Beseitigung dieses Problems nützlich macht, ist, dass sie Parameter zulassen. Das heißt, anstatt so etwas zu tun:

  // Tu das nicht! Vorbehaltlich der Injektion "SELECT credit_card_number FROM user_data wobei userid = '" + userinput + "'"  

Wir können dies tun:

  "SELECT credit_card_number FROM user_data where userid =? " 

Und kompilieren Sie diese Anweisung in der Datenbank. Wenn wir es ausführen, müssen wir einen Parameterwert übergeben, sonst schlägt die Abfrage fehl. Warum löst dies das Problem? Angenommen, ein Angreifer findet heraus, wie er die Zeichenfolge erhält: foo 'ODER 1 = 1 ODER' a '=' a in den Benutzereingabewert. Im ersten Fall wird die folgende SQL ausgeführt:

  SELECT credit_card_number FROM user_data wobei userid = 'foo' ODER 1 = 1 ODER 'a' = 'a';  

Gibt jede Zeile in der Tabelle zurück. Im zweiten Fall wird diese SQL ausgeführt:

  SELECT credit_card_number FROM user_data wobei userid =?  

mit dem Parameter foo 'OR 1 = 1 ODER 'a' = 'a . Wenn Sie keinen Benutzer mit der unwahrscheinlichen ID foo 'ODER 1 = 1 ODER' a '=' a haben, werden keine Ergebnisse angezeigt. Aber lassen Sie uns klar sein, Sie können den ersten (falschen) Ansatz mit vorbereiteten Aussagen verwenden und Sie werden immer noch verwundbar sein. Die vorbereitete Anweisung enthält nichts Magisches, das die Eingabe bereinigt. Sie können den zweiten (korrekten) Ansatz nicht mit einer regulären Anweisung verwenden, die keine Parameter unterstützt.

Ich denke oft, dass Menschen, die Verstehen Sie, dass dies die Abkürzung "Use Prepared Statements" verwendet, da der Hauptgrund für die Verwendung darin besteht, dass sie Parameter unterstützen. Aber es sind wirklich die Parameter, die die Lösung für dieses Problem darstellen.

Zusätzlich zu Matthews großartiger Antwort sind Sie möglicherweise auch dann anfällig für CSRF, wenn Sie Ihren Benutzern vertrauen. Dies kann es einem Angreifer ermöglichen, eine SQL-Injection ohne Konto durchzuführen.

Ein Angreifer kann möglicherweise einen Link oder ein Formular erstellen, auf das ein authentifizierter Benutzer versehentlich klicken oder senden kann, wodurch eine SQL-Injection erfolgt. Aus diesem Grund versichere ich, dass Sie Benutzereingaben niemals vertrauen sollten und dass Sie parametrisierte Abfragen für alle Benutzereingaben bereinigen und verwenden sollten.

Dies ist eine sehr beliebte Frage zum Stapelüberlauf, und deshalb habe ich eine Art "Standardantwort" darauf entwickelt.

1. Warum versuchen Sie zu verhandeln?

Zunächst einmal klingt die Frage so, als würden Sie versuchen, sich einen "Rabatt" in der Entwicklung auszuhandeln. Aber warum versuchst du es so? Warum stellt sich jemals eine solche Frage? Sind vorbereitete Aussagen für Sie zu schwer zu erfassen / umzusetzen? Dann sollten Sie eine andere Frage stellen: "Wie mache ich vorbereitete Aussagen weniger langweilig?" Tatsächlich ist eine vorbereitete Anweisung einfacher als jede andere Methode der Datenbankinteraktion.

Daher gibt es überhaupt keinen Grund für eine solche Frage.

2. SQL-Injection ist nur ein Nebeneffekt .

Sie müssen Ihre Abfragen unabhängig von möglichen Bedrohungen formatieren. Sie tun es nicht für die berühmten Bobby Tables, sondern für ein bescheidenes Mädchen, Sarah O'Hara (oder einen anderen Menschen oder eine andere Entität, die zufällig einen Namen trägt, der eine Datenbank erstellen könnte Choke, wenn nicht richtig formatiert).

Es handelt sich also nicht um eine SQL-Injection, für die Sie vorbereitete Anweisungen verwenden müssen, sondern lediglich, um sicherzustellen, dass Ihre Abfrage immer syntaktisch korrekt ist.

3. Es gibt zu viele mögliche Fallstricke bei der manuellen Formatierung.

Wenn Sie keine vorbereiteten Anweisungen verwenden, sind Sie damit abgefunden, Ihre Daten manuell zu formatieren, und auf diesem Weg gibt es viele Fallstricke. Ich habe mich bemüht, sie in meinem Artikel über SQL-Injection zusammenzufassen. Hier ein Auszug:

1. Die manuelle Formatierung kann unvollständig sein. Nehmen wir den Fall der Bobby Tables. Es ist ein perfektes Beispiel für unvollständige Formatierung: Eine Zeichenfolge, die wir der Abfrage hinzugefügt haben, wurde nur in Anführungszeichen gesetzt, aber nicht maskiert! Während, wie wir gerade aus dem oben Gesagten gelernt haben, Zitieren und Escaping immer zusammenpassen sollten (zusammen mit der Einstellung der richtigen Codierung für die Escape-Funktion). In einer üblichen PHP-Anwendung, die die SQL-Zeichenfolgenformatierung separat ausführt (teilweise in der Abfrage und teilweise an einer anderen Stelle), ist es sehr wahrscheinlich, dass ein Teil der Formatierung einfach übersehen wird.

2. Manuelle Formatierung kann auf das falsche Literal angewendet werden. Keine große Sache, solange wir vollständige Formatierung verwenden (da dies einen sofortigen Fehler verursacht, der behoben werden kann die Entwicklungsphase), aber in Kombination mit unvollständiger Formatierung ist es eine echte Katastrophe. Auf der großartigen Website von Stack Overflow gibt es Hunderte von Antworten, die vorschlagen, Identifikatoren genauso wie Zeichenfolgen zu entkommen. Dies wäre völlig nutzlos und würde eine SQL-Injektion verursachen.

3. Die manuelle Formatierung ist im Wesentlichen eine nicht obligatorische Maßnahme. Zunächst einmal gibt es eine offensichtlicher Mangel an Aufmerksamkeit, bei dem die richtige Formatierung einfach vergessen werden kann. Aber es gibt einen wirklich seltsamen Fall: Viele PHP-Benutzer lehnen es absichtlich ab, Formatierungen anzuwenden, da sie die Daten bis heute in "bereinigen" und "unsauber", "Benutzereingaben" und "getrennt" trennen "Nichtbenutzereingaben" usw. Ich denke, dass "sichere" Daten keine Formatierung benötigen. Was ein einfacher Unsinn ist - erinnern Sie sich an Sarah O'Hara. Aus Sicht der Formatierung ist das Ziel wichtig. Ein Entwickler muss den Typ des SQL-Literal beachten, nicht die Datenquelle. Geht eine Zeichenfolge zur Abfrage? Es muss dann als String formatiert werden. Egal, ob es sich um Benutzereingaben handelt oder nur auf mysteriöse Weise aus dem Nichts inmitten der Codeausführung aufgetaucht ist.

4. Die manuelle Formatierung kann durch einen beträchtlichen Abstand von der tatsächlichen Abfrageausführung getrennt werden.

ol>

Das am meisten unterschätzte und übersehene Problem. Das Wichtigste von allen ist jedoch, dass es alle anderen Regeln allein verderben kann, wenn es nicht befolgt wird.

Fast jeder PHP-Benutzer ist versucht, die gesamte "Desinfektion" an einem einzigen Ort durchzuführen, weit weg von der Die tatsächliche Ausführung von Abfragen und ein derart falscher Ansatz sind allein eine Quelle für unzählige Fehler:

• Da zunächst keine Abfrage vorliegt, kann man nicht sagen, welche Art von SQL-Literal dies für ein bestimmtes Teil darstellt - und somit haben wir beide Formatierungsregeln (1) und (2) gleichzeitig verletzt.
• haben mehr als einen Ort für die Desinfektion (es könnte sich entweder um eine zentralisierte Einrichtung oder um eine direkte Formatierung handeln) Wir fordern eine Katastrophe, da ein Entwickler denkt, dass sie von einem anderen durchgeführt wurde oder bereits an einem anderen Ort hergestellt wurde usw.
• Wenn wir mehr als einen Ort für die Desinfektion haben, führen wir eine weitere Gefahr ein, die doppelte Desinfektion Daten (z. B. ein Entwickler hat sie am Einstiegspunkt formatiert und ein anderer - vor der Ausführung der Abfrage), die nicht gefährlich sind, aber die Website extrem unprofessionell aussehen lassen

• vorzeitige Formatierung verdirbt die Quellvariable und macht sie für alles andere unbrauchbar.

  5. Schließlich nimmt die manuelle Formatierung immer zusätzlichen Platz in der Code, wodurch er verwickelt und aufgebläht wird.
  ol>

4. Eine vorbereitete Aussage ist keine Silberkugel.

Zu guter Letzt. Wir alle müssen uns daran erinnern, dass Datenliterale nicht die einzigen variablen Teile in der Abfrage sind. Manchmal muss auch ein Bezeichner oder ein Schlüsselwort hinzugefügt werden. Vorbereitete Anweisungen helfen in diesem Fall nicht weiter, dennoch sollten solche Abfrageteile insgesamt nicht weniger geschützt sein. Glücklicherweise ist die Liste der möglichen Varianten für Bezeichner und Schlüsselwörter immer begrenzt, sodass wir den Whitelisting -Ansatz verwenden können, den ich in meiner Antwort auf die Referenzfrage zum Stapelüberlauf a beschrieben habe >, damit ich mich nicht wiederhole.

Um Ihre letzte Frage zu beantworten - nein, eine Abfrage ohne variable Teile ist nicht anfällig, da es keinen Grund zum Injizieren gibt.

Es gibt keinen wirklich vertrauenswürdigen Benutzer. Selbst wenn Sie Insider-Bedrohungen ignorieren (was heutzutage ein eklatantes Versehen ist), gibt es andere Risiken. Der Benutzer hat möglicherweise sein Kennwort auf ein Post-It geschrieben, oder sein Gerät ist möglicherweise mit Malware kompromittiert, die Ihre Sicherheitsanfälligkeiten ausnutzt, ohne dass der Benutzer dies weiß.

Indem ein SQL-Injection-Loch any ausgesetzt wird Benutzer gewähren Sie ihnen effektiv uneingeschränkten, nicht überwachten Zugriff auf Ihre Datenbank. Abhängig davon, wie gut Sie Ihr Sicherheitsmodell eingerichtet haben, können sie wahrscheinlich auch alles löschen.

Grundsätzlich müssen Sie entscheiden, vor wem Sie schützen, und Ihre Anstrengungen begründen Wenn Sie jedoch ein SQL-Injection-Loch offen lassen, ist dies nur schlampig und setzt Sie dem Risiko aus, keinen greifbaren Nutzen zu erzielen. Wenn Sie parametrisierte Abfragen korrekt implementieren, sollte es keinen Unterschied in der Anstrengung geben, es richtig zu machen.

Eine letzte Überlegung ... Sicherheit ist keine binäre Sache. Sie sollten viele Ebenen haben, die jeweils vor unterschiedlichen Angriffsvektoren schützen. Wenn eine Ebene gefährdet ist, schützen die verbleibenden Ebenen Ihre Daten (oder verringern den Verlust). In diesem Szenario können Angreifer bei einem standortübergreifenden Anforderungsfälschungsangriff Ihre Datenbank besitzen. Wenn Sie die SQL-Injection gepatcht haben, ist das Schlimmste, was sie tun können, was Ihre App einem Benutzer unter normalen Bedingungen ermöglicht ¹.

¹ (Und um dies zu mildern, können Sie eine Ratenbegrenzung oder eine Überwachung implementieren / Warnsystem. Sie können für immer weitermachen.