Gdybyś wiedział, dlaczego następuje wstrzyknięcie SQL, sam mógłbyś odpowiedzieć na to pytanie.
Zobaczmy. CWE opisuje wstrzykiwanie SQL (CWE-89) w następujący sposób:
Ponadto:
A więc w skrócie:dane wejściowe z wpływami zewnętrznymi w wygenerowanym zapytaniu SQL nie są interpretowane zgodnie z przeznaczeniem. Ważną częścią jest tutaj:niezinterpretowane zgodnie z przeznaczeniem .
Jeśli dane wejściowe użytkownika mają być interpretowane jako ciąg MySQL dosłowny ale tak nie jest, to wstrzyknięcie SQL. Ale dlaczego tak się dzieje?
Cóż, litery tekstowe mają określoną składnię, dzięki której są identyfikowane przez parser SQL:
Dodatkowo:
Dodatkowo, aby móc używać cudzysłowów w literałach ciągu:
Ponieważ wszystkie te ostatnie sekwencje są specyficzne dla literałów łańcuchowych, konieczne jest, aby wszelkie dane, które mają być interpretowane jako literały łańcuchowe, były odpowiednio przetwarzane, aby były zgodne z tymi regułami. Oznacza to w szczególności:jeśli którykolwiek z wymienionych znaków ma być użyty w literale ciągu, musi być zapisany jako jeden ze wspomnianych sposobów.
Więc jeśli spojrzysz na to z tej perspektywy, nie jest to nawet kwestia bezpieczeństwa, ale po prostu przetwarzania danych, aby były interpretowane zgodnie z przeznaczeniem .
To samo dotyczy innych literałów, a także innych aspektów SQL.
A co z twoim pytaniem?
Tak, byłoby to bezpieczne przed wstrzyknięciami SQL. bin2hex zwraca ciąg, który zawiera tylko znaki szesnastkowe. I żaden z tych znaków nie wymaga specjalnego traktowania podczas używania ich w literale ciągu MySQL.
Ale poważnie, dlaczego ktokolwiek miałby chcieć używać tych kłopotliwych technik formatowania, skoro istnieją biblioteki i frameworki, które dostarczają wygodnych technik, takich jak sparametryzowane/przygotowane instrukcje?
