Pokud byste věděli, proč dochází k SQL injection, mohli byste si na tuto otázku odpovědět sami.
Uvidíme. CWE popisuje vkládání SQL (CWE-89) takto:
Dále:
Takže v podstatě:externě ovlivněné vstupy ve vygenerovaném SQL dotazu nejsou interpretovány tak, jak bylo zamýšleno. Zde je důležitá část:neinterpretováno tak, jak bylo zamýšleno .
Pokud má být uživatelský vstup interpretován jako řetězec MySQL doslovný ale není, je to SQL injection. Ale proč se to děje?
Dobře, řetězcové literály mají určitou syntaxi, podle které jsou identifikovány analyzátorem SQL:
Navíc:
Navíc, abyste mohli používat uvozovky v řetězcových literálech:
Protože všechny tyto posledně jmenované sekvence jsou speciální pro řetězcové literály, je nutné, aby všechna data, která mají být interpretována jako řetězcový literál, byla řádně zpracována, aby odpovídala těmto pravidlům. To konkrétně znamená:pokud má být některý ze zmíněných znaků použit v řetězcovém literálu, musí být zapsán jedním ze zmíněných způsobů.
Takže když se na to podíváte z tohoto pohledu, nejde ani tak o bezpečnost, ale prostě o zpracování dat tak, aby byla interpretována tak, jak bylo zamýšleno .
Totéž platí pro ostatní literály a také další aspekty SQL.
A co vaše otázka?
Ano, to by bylo bezpečné před SQL injekcemi. bin2hex vrátí řetězec, který obsahuje pouze hexadecimální znaky. A ani jeden z těchto znaků nevyžaduje zvláštní zacházení, když je používáte v řetězcovém literálu MySQL.
Ale vážně, proč by někdo chtěl používat tyto těžkopádné formátovací techniky, když existují knihovny a rámce, které poskytují pohodlné techniky, jako jsou parametrizované/připravené příkazy?