Als je zou weten waarom een SQL-injectie plaatsvindt, zou je deze vraag zelf kunnen beantwoorden.
Laten we zien. De CWE beschrijft SQL-injecties (CWE-89) als volgt:
Verder:
Dus eigenlijk:extern beïnvloede invoer in een gegenereerde SQL-query wordt niet geïnterpreteerd zoals bedoeld. Het belangrijkste hier is:niet geïnterpreteerd zoals bedoeld .
Als een gebruikersinvoer bedoeld is om te worden geïnterpreteerd als een MySQL-tekenreeks letterlijk maar dat is het niet, het is een SQL-injectie. Maar waarom gebeurt het?
Nou, tekenreeksletters een bepaalde syntaxis hebben waarmee ze worden geïdentificeerd door de SQL-parser:
Bovendien:
Bovendien, om aanhalingstekens te kunnen gebruiken in letterlijke tekenreeksen:
Aangezien al deze laatstgenoemde reeksen speciaal zijn voor letterlijke tekenreeksen, is het noodzakelijk dat alle gegevens die bedoeld zijn om te worden geïnterpreteerd als een letterlijke tekenreeks, correct worden verwerkt om te voldoen aan deze regels. Dit betekent in het bijzonder:als een van de genoemde tekens bedoeld is om in een letterlijke tekenreeks te worden gebruikt, moeten ze op een van de genoemde manieren worden geschreven.
Dus als je het van deze kant bekijkt, is het niet eens een kwestie van veiligheid maar gewoon van gegevens verwerken zodat ze worden geïnterpreteerd zoals bedoeld .
Hetzelfde geldt voor de andere letterlijke en andere aspecten van SQL.
Dus hoe zit het met uw vraag?
Ja, dat zou veilig zijn voor SQL-injecties. bin2hex retourneert een tekenreeks die alleen hexadecimale tekens bevat. En geen van deze karakters heeft een speciale behandeling nodig wanneer ze worden gebruikt in een letterlijke MySQL-string.
Maar serieus, waarom zou iemand deze omslachtige opmaaktechniek willen gebruiken als er bibliotheken en frameworks zijn die handige technieken bieden, zoals geparametriseerde/voorbereide instructies?