在平时的开发过程中，关于代码中存在SQL注入的问题，想必大家都有所认识和了解，也都知道通用的解决方案。
但最近看到另外一种防止SQL注入的方式是这样的：
<code>$sql = sprintf("SELECT * FROM `test1` WHERE `name` = unhex('%s')", bin2hex($name));</code>
即先使用PHP自带的函数bin2hex函数将输入待查询字符串处理成16进制字符串，然后再SQL执行过程中使用数据库本身的unhex函数将该16进制字符串反转为原先的正常字符串。
这样即便$name的值为'maratrix' or 1 = 1也会正常被当作查询字符串处理，而不存在SQL注入的问题了。
查了下相关资料，也没有弄明白这其中能够绕过SQL注入的原理，希望大家帮助解释下其中的原因。
谢谢~
回复内容：
在平时的开发过程中，关于代码中存在SQL注入的问题，想必大家都有所认识和了解，也都知道通用的解决方案。
但最近看到另外一种防止SQL注入的方式是这样的：
<code>$sql = sprintf("SELECT * FROM `test1` WHERE `name` = unhex('%s')", bin2hex($name));</code>
（本文来）源gaodaimacom搞#^代%!码&网(
搞gaodaima代码
即先使用PHP自带的函数bin2hex函数将输入待查询字符串处理成16进制字符串，然后再SQL执行过程中使用数据库本身的unhex函数将该16进制字符串反转为原先的正常字符串。
这样即便$name的值为'maratrix' or 1 = 1也会正常被当作查询字符串处理，而不存在SQL注入的问题了。
查了下相关资料，也没有弄明白这其中能够绕过SQL注入的原理，希望大家帮助解释下其中的原因。
谢谢~
bin2hex之后$name就全部转换成hex格式的数据了，在拼接到sql里面之后就不会产生存在漏洞的语句了。最好还是建议你让$name的值为maratrix' or 1 = 1，然后把$sql的值echo一下就明白了。
因为unhex是mysql函数，在mysql里面执行自然就没问题了。
SELECT * FROM test1 WHERE name = unhex(‘6d6172617472697827206f722031203d2031’);
name无论啥值，都不会拆分sql了。
转载请注明原文链接：一个通过使用UNHEX绕过SQL注入的问题
