Hvis du vidste, hvorfor en SQL-injektion opstår, ville du selv kunne besvare dette spørgsmål.
Lad os se. CWE beskriver SQL-injektioner (CWE-89) som følger:
Desuden:
Så dybest set:eksternt påvirkede input i en genereret SQL-forespørgsel fortolkes ikke efter hensigten. Den vigtige del her er:ikke fortolket efter hensigten .
Hvis et brugerinput er beregnet til at blive fortolket som en MySQL-streng bogstaveligt men det er det ikke, det er en SQL-injektion. Men hvorfor sker det?
Nå, strengliterals har en bestemt syntaks, som de identificeres med af SQL-parseren:
Derudover:
Derudover for at kunne bruge anførselstegn inden for strenge bogstaver:
Da alle disse sidstnævnte sekvenser er specielle for strengliteraler, er det nødvendigt, at enhver data, der er beregnet til at blive fortolket som en strengliteral, behandles korrekt for at overholde disse regler. Dette betyder især:hvis nogen af de nævnte tegn er beregnet til at blive brugt i en streng-literal, skal de skrives som en af de nævnte måder.
Så hvis man ser på det fra denne måde, er det ikke engang et spørgsmål om sikkerhed, men blot om at behandle data, så de bliver fortolket efter hensigten .
Det samme gælder for de andre bogstaver såvel som andre aspekter af SQL.
Så hvad med dit spørgsmål?
Ja, det ville være sikkert fra SQL-injektioner. bin2hex returnerer en streng, der kun indeholder hexadecimale tegn. Og ingen af disse tegn kræver en særlig behandling, når de bruges i en MySQL-streng.
Men seriøst, hvorfor skulle nogen ønske at bruge denne besværlige formateringsteknik, når der er biblioteker og rammer, der leverer praktiske teknikker som parametriserede/forberedte sætninger?