宽字节注入
原理:宽字节(两字节)带来的安全问题主要是吃ASCII字符(一字节)的现象,使用一些特殊字符来”吃掉“经过转义符 “ \ ” 。
在重新详细了解宽字节注入之前,我认为宽字节注入只是出现在网站使用GBK编码的时代,现在已经很少出现了,但是实际上宽字节不只是出现在GBK编码中。
在PHP中,通过iconv()进行编码转换时,也可能出现宽字节注入。
还有一个误区:
这里的编码问题不是出现在HTML页面编码,而是与数据库的编码形式有关,一般我们在建立一个数据库的时候会让我们选择数据库的编码形式,所以有时候网站虽然是UTF-8写的,但是如果数据库是GBK的形式,也会出现宽字节,现实这样建站的奇葩应该很少叭。。。
宽字节编码有哪些:
GB2312、GBK、GB18030、BIG5、Shift_JIS等这些都是常说的宽字节
MySQL中用于转义的函数有:
addslashes、mysql_real_escape_string、mysql_escape_string以及后面在高版本被去除的magic_quote_gpc
绕过思路:
因为宽字节注入主要是吃掉 \ ,所以一般时候加一个 %df 这种就可以吃掉,其实加三个%df也可以吃掉,只要是奇数个%df即可。
防御方法:
1.设置character_set_client=binary,将数据以二进制形式传递
2.矫正人们对于mysql_real_escape_string的误解,单独调用set names gbk和mysql_real_escape_string是无法避免宽字符注入问题的。还得调用mysql_set_charset来设置一下字符集。
3.谨慎使用iconv来转换字符串编码,很容易出现问题。只要我们把前端html/js/css所有编码设置成gbk,mysql/php编码设置成gbk,就不会出现乱码问题。不用画蛇添足地去调用iconv转换编码,造成不必要的麻烦。
参考连接:
1
2
今天的文章宽字节注入原理详解_一个char几个字节分享到此就结束了,感谢您的阅读。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/71921.html