,,,,,
其实数据库安全就那点事,SQL注入。现代Web数据安全方面,相当一部分公司其实并不重视数据安全的问题,据国外统计超过一半的网站可能存在SQL注入漏洞。
,,就说最近的例子,2016年11月30日某某著名公司发送短信邀请本人参加云产品峰会,收到邀请的二维码短信的url,这个url的IP地址就是管理后台就不说了(大家应该知道是谁了,看完本文* * *他人网站的,自负责任)。在用户名输入框中直接输入或1=1,连密码都不需要输入,超级管理员验证通过,直达管理员后台。
,,话说,SQL注入漏洞这个事,能怪谁呢?
,,能怪整天整宿忙碌于擦屁屁的运维吗?能怪搞数据库的DBA吗?
,,严格地说,他们都有责任搞好安全这点事。不过,说到本质,还真与他们没有什么关系。
,,有时候,程序在输入框做好可疑字符过滤,甚至就多加一点逻辑判断,安全就能完全避免的事。但是他们为什么就不做这个检查呢,是人安全意识问题,还是对SQL注入不了解呢?
,, SQL注入漏洞的本质原因并不是在运维工作层面有多大的疏忽,而是程序员没有做好过滤和逻辑上的问题。为什么?
,我们咋一看这个判断过程好像也没有什么问题。那我们来看捣蛋是怎么捣蛋的?
,直接在用户名的输入框输入:1 & # 39;或1=& # 39;1 & # 39;;#,密码输入框不需要填写任何字符,直接回车。这样直接验证通过,到达管理员后台,轻松获得网络管理员权限,当然还有其它效果一样的输入。
,,为什么这样可以得到Web管理员权限呢?我们来把动作分解一下。
,,当捣蛋鬼在用户名输入框输入:1 & # 39;或1=& # 39;1 & # 39;;#,那么传到程序处理加单引号后变成:美元uname=? # 39; 1 & # 39;或1=& # 39;1 & # 39;“,通过美元=啊?这种结果传到SQL语句在数据库中执行就会是这样:select count(*)从userswhere uname=& # 39; 1 & # 39;或1=& # 39;1 & # 39;;#和密码=啊?大家可以执行在一下,这条结果明显把逻辑改变了,结果不可能为空,或的逻辑永远为真,结果不可能为空。非空即为真,管理员登录成功,尤其是表中只有一个管理员的情况更糟糕了。
