深入分析SQL字符串限制长度漏洞 |
本文标签:MySQL字符串 MySQL字符串的限制长度看似重要性不要,其实和整个MySQL数据库的安全性是息息相关的,很值得我们去深入研究分析 。 SQL注入攻击一直都在被广泛的讨论,然而人们却忽略了今天我将要介绍的这两个安全隐患,那就是超长SQL查询和单列SQL字符长度限制可能会带来的问题 。 首先我们来谈论一下超长SQL查询 max_packet_size 如果访问者有可能控制你的sql长度,那么你的程序可能会受到攻击 。哪些情况访问者可能控制sql的长度呢,比如不限制关键字长度的搜索 。还有可能就是你的程序如果要将用户的登录作为日志启用,总之凡是涉及到超长sql查询的地方,一定得小心检查自己的sql,防止超长而查询失效 。不过说实在的,本人认为这个问题倒不是多大,数据库光里管理员也可以自行设置MySQL的max_packet_size的长度,或者在处理可能超长的SQL查询的时候做一个长度判断 。 MySQL列长度限制 该web应用允许用户注册(开放注册的wordpress满足此条件); 首先攻击者用已知的超级管理员id如admin注册,那么这个时候程序就会用 (show/hide)plain text 但是如果攻击者用 admin X(admin和x之间有11个或以上的空格)来注册呢,按照上面的判断,由于admin x不存在数据库中,所以当然就能注册成功了,事实上wordpress2.6.1之前的版本确实可以这样,由于列长度的限制在16个字符内,所以末尾的x就被截掉了,那么现在数据库中就存在两个一模一样的用户admin了 。(旁白:糟糕,那我的程序不是都要去修改 。其实没有必要,你只要把ID设置为UNIQUE就可以了,于是乎,下面的问题就和你没有关系了) 攻击者继续,这个时候攻击者就顺利的注册了admin这个用户名,然后攻击者用admin和自己的密码登录进入账户管理(wordpress即使注册了也无法登陆),由于真正的admin的帐号先于攻击者admin注册,所以在账户信息页面,显示的信息非常有可能就是真正admin的信息,包括密码提示和email等,这个时候攻击者就可以对admin的信息进行任意修改,包括密码和密码找回 。 所以,写web程序的你,是不是该去检查一下自己的程序是否有此类的漏洞呢 。
|