SQL注入全过程深入分析
本文分析了sql注入全过程。分享给大家供大家参考,具体如下:
初步注入--绕过验证,直接登录
公司网站登陆框如下:
可以看到除了账号密码之外,还有一个公司名的输入框,根据输入框的形式不难推出sql的写法如下:
我发现前两者都做一些检查,而第三个输入框却疏忽了,漏洞就在这里!注入开始,在输入框中输入以下内容:
用户名乱填,密码留空,这种情况下点击登录按钮后竟然成功登录了。
我们看一下最终的sql就会找到原因:
从代码可以看出,前一半单引号被闭合,后一半单引号被 “--”给注释掉,中间多了一个永远成立的条件“1=1”,这就造成任何字符都能成功登录的结果。而sql注入的危害却不仅仅是匿名登录。
中级注入--借助异常获取信息
现在我们在第三个输入框中写入:
‘or 1=(select @@version) –
如下:
后台的sql变成了这样:
select * from table where name='sql inject' and password='' and corp='' or 1=(select @@version)--'
判断条件变成了1=(select @@version),
这个写法肯定会导致错误,但出错正是我们想要的。点击登录后,页面出现以下信息:
conversion failed when converting the nvarchar value 'microsoft sql server 2008 (sp3) - 10.0.5500.0 (x64) sep 21 2011 22:45:45
copyright (c) 1988-2008 microsoft corporation developer edition (64-bit)
on windows nt 6.1 <x64> (build 7601: service pack 1) ' to data type int.
可怕的事情出现了,服务器的操作系统和sql server版本信息竟然通过错误显示出来。
危害扩大--获取服务器所有的库名、表名、字段名
接着,我们在输入框中输入如下信息:
此时发现第三个输入框有字数长度的限制,然而这种客户端的限制形同虚设,
直接通过google浏览器就能去除。
点击登录,返回的信息如下:
conversion failed when converting the nvarchar value 'master' to data type int.
数据库名称“master”通过异常被显示出来!依次改变上面sql语句中的序号,
就能得到服务器上所有数据库的名称。
接着,输入信息如下:
得到返回信息如下:
conversion failed when converting the nvarchar value 'spt_fallback_db' to data type int.
我们得到了master数据库中的第一张表名:“spt_fallback_db”,
同上,依次改变序号,可得到该库全部表名。
现在我们以“spt_fallback_db”表为例,尝试获取该表中所有的字段名。在输入框中输入以下代码:
于是,得到错误提示如下:
"conversion failed when converting the nvarchar value 'xserver_name' to data type int.";
这样第一个字段名“xserver_name”就出来了,依次改变序号,就能遍历出所有的字段名。
最终目的--获取数据库中的数据
写到这里,我们已知通过sql注入能获取全部的数据库,表,及其字段,为了防止本文完全沦为注入教程,获取数据的代码就不再描述,而这篇文章的目的也已达到,sql注入意味着什么?意味着数据库中所有数据都能被盗取。
当知道这个危害以后,是否还能有人对sql注入漏洞置之不理?
结语
关于安全性,本文可总结出一下几点:
1. 对用户输入的内容要时刻保持警惕。
2. 只有客户端的验证等于没有验证。
3. 永远不要把服务器错误信息暴露给用户。
除此之外,我还要补充几点:
1. sql注入不仅能通过输入框,还能通过url达到目的。
2. 除了服务器错误页面,还有其他办法获取到数据库信息。
3. 可通过软件模拟注入行为,这种方式盗取信息的速度要比你想象中快的多。
4. 漏洞跟语言平台无关。
上一篇: Redis简单cluster集群搭建