Wenn Sie wüssten, warum eine SQL-Injection auftritt, könnten Sie diese Frage selbst beantworten.
Mal schauen. Der CWE beschreibt SQL-Injections (CWE-89) wie folgt:
Außerdem:
Also im Grunde:Von außen beeinflusste Eingaben in einer generierten SQL-Abfrage werden nicht wie beabsichtigt interpretiert. Der wichtige Teil hier ist:nicht wie beabsichtigt interpretiert .
Wenn eine Benutzereingabe als MySQL-String interpretiert werden soll wörtlich aber das ist es nicht, es ist eine SQL-Injection. Aber warum passiert das?
Nun, String-Literale haben eine bestimmte Syntax, durch die sie vom SQL-Parser identifiziert werden:
Zusätzlich:
Um Anführungszeichen innerhalb von String-Literalen verwenden zu können:
Da alle diese letztgenannten Sequenzen speziell für Zeichenfolgenliterale sind, ist es erforderlich, dass alle Daten, die als Zeichenfolgenliterale interpretiert werden sollen, ordnungsgemäß verarbeitet werden, um diesen Regeln zu entsprechen. Das bedeutet insbesondere:Wenn eines der genannten Zeichen in einem String-Literal verwendet werden soll, muss es auf eine der genannten Arten geschrieben werden.
So gesehen geht es also nicht einmal um die Sicherheit, sondern lediglich darum, Daten so aufzubereiten, dass sie bestimmungsgemäß interpretiert werden .
Dasselbe gilt für die anderen Literale sowie andere Aspekte von SQL.
Was ist mit Ihrer Frage?
Ja, das wäre sicher vor SQL-Injections. bin2hex gibt eine Zeichenfolge zurück, die nur hexadezimale Zeichen enthält. Und keines dieser Zeichen erfordert eine besondere Behandlung, wenn es in einem MySQL-String-Literal verwendet wird.
Aber im Ernst, warum sollte irgendjemand diese umständliche Formatierungstechnik verwenden wollen, wenn es Bibliotheken und Frameworks gibt, die praktische Techniken wie parametrisierte/vorbereitete Anweisungen bereitstellen?
