Vorbereitete SQL-Anweisungen und Tabellennamen: Eine häufige Gefahr
Vorbereitete Anweisungen sind für sichere SQL-Abfragen von entscheidender Bedeutung und verhindern SQL-Injection-Schwachstellen. Ein häufiges Missverständnis besteht jedoch darin, dass Tabellennamen innerhalb einer vorbereiteten Anweisung parametrisiert werden können. Das ist falsch.
Das folgende Beispiel veranschaulicht das Problem: Der Versuch, eine vorbereitete Anweisung zu verwenden, um einen Tabellennamen (z. B. query1
) mithilfe eines Parameters ([?]
) und einer Variablen wie reportDate
dynamisch anzugeben, schlägt fehl. Der Fehler „Parameter ‚Pa_RaM000‘ angegeben, wo ein Tabellenname erforderlich ist“ verdeutlicht diese Einschränkung.
Die Lösung: Dynamische Konstruktion außerhalb der vorbereiteten Aussage
Das Kernproblem besteht darin, dass SQL-Parser Tabellennamen anders behandeln als andere Abfrageparameter. Sie können nicht dynamisch über vorbereitete Anweisungsplatzhalter eingefügt werden.
Der richtige Ansatz besteht darin, den Tabellennamen dynamisch zu erstellen, bevor die vorbereitete Anweisung verwendet wird. Dies geschieht durch Verketten der Variablen, die den Datumsteil enthält (z. B. reportDate
), mit den festen Teilen des Tabellennamens:
<code class="language-sql">private String query1 = "SELECT plantID, edrman, plant, vaxnode FROM [" + reportDate + ".?]";</code>
Hier stellt reportDate
den datumsspezifischen Teil des Tabellennamens bereit, der mit dem statischen Teil kombiniert wird. Die übrigen Parameter innerhalb der SELECT
-Anweisung können dann sicher innerhalb der vorbereiteten Anweisung selbst parametrisiert werden.
Diese Methode ermöglicht die dynamische Abfragegenerierung und behält gleichzeitig die Sicherheitsvorteile vorbereiteter Anweisungen für die Datenwerte bei.
Das obige ist der detaillierte Inhalt vonWarum kann ich vorbereitete Anweisungen nicht für Tabellennamen in SQL verwenden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!