Ако знаехте защо възниква SQL инжекция, щяхте сами да отговорите на този въпрос.
Да видим. CWE описва SQL инжекции (CWE-89) както следва:
Освен това:
Така че основно:външно повлияните входове в генерирана SQL заявка не се интерпретират по предназначение. Важната част тук е:не се тълкува по предназначение .
Ако въведеното от потребителя е предназначено да се интерпретира като MySQL низ буквално но не е, това е SQL инжекция. Но защо се случва?
Е, низови литерали имат определен синтаксис, чрез който се идентифицират от SQL анализатора:
Допълнително:
Освен това, за да можете да използвате кавички в низови литерали:
Тъй като всички тези последни споменати последователности са специални за низовите литерали, е необходимо всички данни, които са предназначени да бъдат интерпретирани като низови литерали, да бъдат правилно обработени, за да отговарят на тези правила. Това означава по-специално:ако някой от споменатите знаци е предназначен да се използва в низов литерал, той трябва да бъде написан по един от споменатите начини.
Така че, ако погледнете от този начин, това дори не е въпрос на сигурност, а просто на обработване на данни, така че да бъдат интерпретирани по предназначение .
Същото важи и за другите литерали, както и за други аспекти на SQL.
И така, какво ще кажете за вашия въпрос?
Да, това би било безопасно от SQL инжекции. bin2hex връща низ, който съдържа само шестнадесетични знаци. И нито един от тези знаци не изисква специално третиране, когато се използва в MySQL низов литерал.
Но сериозно, защо някой би искал да използва тези тромави техники за форматиране, когато има библиотеки и рамки, които предоставят удобни техники като параметризирани/подготвени оператори?
