Se você soubesse por que ocorre uma injeção de SQL, seria capaz de responder a essa pergunta por conta própria.

Vamos ver. O CWE descreve injeções de SQL (CWE-89) do seguinte modo:

Além disso:

Então, basicamente:entradas influenciadas externamente em uma consulta SQL gerada não são interpretadas como pretendido. A parte importante aqui é:não interpretado como pretendido .

Se uma entrada do usuário for interpretada como uma string MySQL literal mas não é, é uma injeção de SQL. Mas por que isso acontece?

Bem, literais de string têm uma certa sintaxe pela qual são identificados pelo analisador SQL:

Adicionalmente:

Além disso, para poder usar aspas em literais de string:

Como todas essas últimas sequências mencionadas são especiais para literais de string, é necessário que qualquer dado, que se pretenda interpretar como um literal de string, seja processado adequadamente para estar em conformidade com essas regras. Isso significa em particular:se algum dos caracteres mencionados for destinado a ser usado em uma string literal, eles devem ser escritos de uma das maneiras mencionadas.

Então, se você olhar dessa forma, não é nem mesmo uma questão de segurança, mas simplesmente de processar dados para que eles sejam interpretados como pretendido .

O mesmo se aplica aos outros literais, bem como a outros aspectos do SQL.

Então e a sua pergunta?

Sim, isso seria seguro contra injeções de SQL. bin2hex retorna uma string que contém apenas caracteres hexadecimais. E nenhum desses caracteres requer um tratamento especial ao usá-los em uma string literal do MySQL.

Mas falando sério, por que alguém iria querer usar essa técnica de formatação complicada quando existem bibliotecas e frameworks que fornecem técnicas convenientes como instruções parametrizadas/preparadas?