Om du visste varför en SQL-injektion inträffar, skulle du kunna svara på den här frågan själv.
Låt oss se. CWE beskriver SQL-injektioner (CWE-89) enligt följande:
Dessutom:
Så i grund och botten:externt påverkade indata i en genererad SQL-fråga tolkas inte som avsett. Den viktiga delen här är:inte tolkad som avsett .
Om en användarinmatning är avsedd att tolkas som en MySQL-sträng bokstavligt men det är det inte, det är en SQL-injektion. Men varför händer det?
Tja, strängliterals har en viss syntax genom vilken de identifieras av SQL-parsern:
Dessutom:
Dessutom, för att kunna använda citattecken inom sträng bokstaver:
Eftersom alla dessa sistnämnda sekvenser är speciella för strängliteraler, är det nödvändigt att all data, som är avsedd att tolkas som en strängliteral, bearbetas korrekt för att överensstämma med dessa regler. Detta betyder särskilt:om någon av de nämnda tecknen är avsedd att användas i en bokstavlig sträng måste de skrivas som ett av de nämnda sätten.
Så om man ser det från det här sättet är det inte ens en fråga om säkerhet utan bara om att bearbeta data så att de tolkas som avsett .
Detsamma gäller de andra bokstavliga texterna såväl som andra aspekter av SQL.
Så hur är det med din fråga?
Ja, det skulle vara säkert från SQL-injektioner. bin2hex returnerar en sträng som endast innehåller hexadecimala tecken. Och ingen av dessa karaktärer kräver någon speciell behandling när de används i en MySQL-sträng.
Men seriöst, varför skulle någon vilja använda den här besvärliga formateringstekniken när det finns bibliotek och ramverk som tillhandahåller praktiska tekniker som parametriserade/förberedda uttalanden?