宽字节注入

宽字节注入

宽字节注入基础

GBK占用两字节,ASCII占用一字节,PHP中编码为GBK,函数执行添加的是ASCII编码,MySQL默认的字符集是GBK等宽字节字符集

在数据库中使用了宽字符集(GBK,GB2312等),除了英文都是一个字符占两字节;

MySQL在使用GBK编码的时候,会认为两个字符为一个汉字(ascii>128才能达到汉字范围);

在PHP中使用addslashes函数的时候,会对单引号%27进行转义,在前边加一个反斜杠”\”,变成%5c%27;

可以在前边添加%df,形成%df%5c%27,而数据进入数据库中时前边的%df%5c两字节会被当成一个汉字;

%5c被吃掉了,单引号由此逃逸可以用来闭合语句。

程序员为了防止sql注入,对用户输入中的单引号(’)进行处理,在单引号前加上斜杠(\)进行转义,这样被处理后的sql语句中,单引号不再具有‘作用’,仅仅是‘内容’而已,换句话说,这个单引号无法发挥和前后单引号闭合的作用,仅仅成为‘内容‘

而安全测试人员要绕过这个转义处理,使单引号发挥作用,有两个思路:

  1. 让斜杠(\)失去作用(对反斜杠(\)转义,使其失去转义单引号的作用,成为‘内容’)

  2. 让斜杠(\)消失(宽字节注入)

修复建议

  • 统一使用utf-8字符集

utf-8字符集可以说是非常安全的字符集了,但是并不代表100%安全。

​ 使用PHP函数iconv('utf-8','gbk',$_GET['id']),也可能导致注入产生iconv导致的致命后果

$result=mysqli_query("character_set_client=binary", $sql);

至于为什么设置character_set_client=binary就能防止宽字节注入,百度了很多资料,都是一笔带过模糊不清。在知乎里的一个回答,我是比较赞同的,但是他也并不清楚原因。

MySQL在传输时确定语义的一层就是character_set_client与后面的无关。

根据我的测试可以肯定的是如果设置character_set_client=binary在这一层的编码上语义肯定发生了一些改变导致后面的恶意语句变成了无效编码从而被MySQL截断了,至于具体改变了什么就无从得知了。

挖个坑以后有机会再来填了

其实学到这里已经感觉到了SQL注入是什么一种感觉了这话说的有点虚无缥缈纳

SQL注入和宽字节注入都是常见的安全漏洞类型。下面我将简要介绍这两种注入方式。 1. SQL注入: SQL注入是一种在应用程序中利用不正确处理用户输入的漏洞,攻击者可以通过在用户输入中插入恶意的SQL代码来执行非授权的数据库操作。这可能导致数据泄露、数据篡改、绕过认证、获取系统权限等问题。 预防SQL注入的措施包括: - 使用参数化查询或预编译语句来处理数据库查询,而不是直接拼接用户输入的数据。 - 对用户输入进行严格的验证和过滤,避免将未经处理的输入直接传递给数据库查询。 - 最小化数据库用户的权限,并且仅分配最低必要的权限。 2. 宽字节注入宽字节注入是一种特定于某些数据库和编码方式的注入攻击方法。它利用了某些编码方式对特殊字符的处理不当,从而绕过了应用程序对输入进行过滤和验证的机制。攻击者可以通过插入字节字符来篡改SQL语句或绕过认证。 预防宽字节注入的措施包括: - 使用合适的编码方式,例如UTF-8,以避免特殊字符被误解释。 - 进行输入验证和过滤,确保特殊字符被正确处理,不会导致SQL语句的非预期解析。 - 定期更新数据库和应用程序框架,以修复已知的宽字节注入漏洞。 总的来说,要防止SQL注入和宽字节注入等安全漏洞,应该采取综合性的安全措施,包括输入验证、参数化查询、最小权限原则、使用最新版本的软件以及定期进行安全审计和漏洞扫描。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值