Heim > Artikel > Backend-Entwicklung > 一个通过使用UNHEX绕过SQL注入的问题
在平时的开发过程中,关于代码中存在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>
即先使用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了。