Was ist Second Level SQL Injection

Question

Was hat es mit der SQL-Injection der zweiten Ebene auf sich? Dies ist mit Bezug auf die Frage Verwendung von Parametern für mysql_query ... und ein Teil einer der Antworten enthielt diesen Begriff...

Answer 1

Ich bin mir nicht ganz sicher, aber ich dachte, es sei in dem Beitrag "definiert": Verwendung von Parametern für mysql_query

Auszug (siehe Punkt 2):

magic_quotes_gpc automatisch Dinge, die Sie in Anfragen von Clients erhalten von Clients... aber es kann nicht erkennen sogenannte Second-Level-Injektionen:

1. Sie erhalten eine bösartige Anfrage von einem Client und speichern deren Inhalt in der Datenbank. magic_quotes_gpc verhindert SQL-Injektion; die bösartige Zeichenfolge wird korrekt gespeichert.
2. Später holen Sie diese Zeichenfolge aus der Datenbank und fügen sie in eine eine andere Abfrage ein. Die Zeichenkette stammt nun nicht aus einer Anfrage, also magic_quotes_gpc entgeht nicht dem Zeichenfolge. Voilà, SQL-Injektion; Ihre Daten sind jetzt wahrscheinlich weg.

Hier ist eine andere, die ich gegoogelt habe ( http://www.osix.net/modules/article/?id=624 ):

Beachten Sie, dass Variablen innerhalb einer gespeicherten Prozedur nicht immer immun sind gegen SQL Injektion gefeit sind. Wenn die gespeicherte Prozedur Konstrukte enthält, die eine eine zweite Ebene des Parsings hinzufügen, wie zum Beispiel EXEC auf eine Zeichenkette in MS SQL Server, müssen Sie müssen Sie Metazeichen behandeln wieder behandeln. Dieses Mal innerhalb der gespeicherten Prozedur.

Answer 2

Wenn Sie niemals davon ausgehen, dass Jegliche Daten, die Sie in eine Abfrage eingeben, "sicher" sind, sollten Sie keine Probleme mit SQL Injection haben. Selbst wenn <religiöses Symbol einfügen> Er/sie gibt Ihnen ein Stück Daten und sagt Ihnen, Sie sollen es in eine SQL-Abfrage einfügen... Sie sollten es trotzdem überprüfen! xD

Es ist eine gute Idee, immer zu versuchen, die Parametrisierte Anweisungen bei der Ausführung von Abfragen. Auf diese Weise ist der Datenbanktreiber selbst für das Entkommen potenziell schädlicher Daten verantwortlich, was das Risiko jeglicher Art von SQL-Injection erheblich verringert.