Si supiera por qué ocurre una inyección SQL, podría responder esta pregunta usted mismo.
Vamos a ver. El CWE describe inyecciones SQL (CWE-89) de la siguiente manera:
Además:
Básicamente:las entradas influenciadas externamente en una consulta SQL generada no se interpretan según lo previsto. La parte importante aquí es:no interpretado según lo previsto .
Si la entrada de un usuario está destinada a interpretarse como una cadena MySQL literal pero no lo es, es una inyección SQL. Pero, ¿por qué sucede?
Bueno, literales de cadena tienen una cierta sintaxis por la cual son identificados por el analizador SQL:
Además:
Además, para poder usar comillas dentro de cadenas literales:
Como todas estas secuencias mencionadas en último lugar son especiales para los literales de cadena, es necesario que cualquier dato, que pretenda interpretarse como un literal de cadena, se procese correctamente para cumplir con estas reglas. Esto significa en particular:si cualquiera de los caracteres mencionados está destinado a ser utilizado en un literal de cadena, debe escribirse como una de las formas mencionadas.
Entonces, si lo miras de esta manera, ni siquiera es una cuestión de seguridad, sino simplemente de procesar datos para que se interpreten según lo previsto. .
Lo mismo se aplica a los demás literales, así como a otros aspectos de SQL.
Entonces, ¿qué pasa con tu pregunta?
Sí, eso estaría a salvo de las inyecciones de SQL. bin2hex devuelve una cadena que contiene solo caracteres hexadecimales. Y ninguno de estos caracteres requiere un tratamiento especial al usarlos en un literal de cadena de MySQL.
Pero en serio, ¿por qué alguien querría usar estas engorrosas técnicas de formato cuando existen bibliotecas y marcos que brindan técnicas convenientes como declaraciones parametrizadas/preparadas?
