漏洞系列之——SQL注入

本文主要是介绍漏洞系列之——SQL注入，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

了解SQL注入

• • 漏洞描述
  • 漏洞等级
  • 漏洞危害
  • 漏洞检测方法
  • 漏洞利用方法
  • 漏洞修复方案

SQL注入靶场环境可以参考“热门靶场怕坑练习”的sqli-labs

漏洞描述

SQL注入是网站存在最多也是最简单的漏洞，主要原因是程序员在设计程序时，忽略了对输入字符串中夹带的SQL指令的检查，被数据库误认为是正常的SQL指令而运行，从而使数据库受到攻击，可能导致数据被窃取、更改、删除，以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。

漏洞等级

高危

漏洞危害

SQL注入的危害不仅体现在数据库层面上，还有可能危及承载数据库的操作系统；如果SQL注入被用来挂马，还可能用来传播恶意软件等，这些危害包括但不局限于：

（1）数据库信息泄漏：数据库中存放的用户的隐私信息的泄露。作为数据的存储中心，数据库里往往保存着各类的隐私信息，SQL注入攻击能导致这些隐私信息透明于攻击者。

（2）网页篡改：通过操作数据库对特定网页进行篡改。

（3）网站被挂马，传播恶意软件：修改数据库一些字段的值，嵌入网马链接，进行挂马攻击。

（4）数据库被恶意操作：数据库服务器被攻击，数据库的系统管理员帐户被篡改。

（5）服务器被远程控制，被安装后门。经由数据库服务器提供的操作系统支持，让黑客得以修改或控制操作系统。

（6）破坏硬盘数据，瘫痪全系统。

漏洞检测方法

可以在正常的url后面跟：%5c，单引号，双引号，反斜杠，负数， 特殊字符，and，or，xor探测是否存在注入。

注释符#和­­+交替用，一定要在注释符号后加空格，这个是个小坑哈。

1、先判断是数字型还是字符型
2、接着判断有没有括号
3、后面跟上­­+或者#注释符，把后面的代码内容注释掉
4、order by判断字段数，如果没法判断，则直接上union select 1,2,3
5、如果返回的页面发生变化，则联合查询
6、如果union select 1,version(),3返回的页面没有发生变化，即联合查询失败，则尝试报错注入
7、如果报错注入页面也没有把信息显示出来，则延时注入

漏洞利用方法

注入点分类：

（1）数字型注入点 在 Web 端大概是 http://xxx.com/news.php?id=1 这种形式，其注入点 id
类型为数字，所以叫数字型注入点。这一类的 SQL 语句原型大概为 select from 表名 where
id=1。组合出来的sql注入语句为：select from news where id=1 and 1=1

（2）字符型注入点 在Web 端大概是 http://xxx.com/news.php?name=admin 这种形式，其注入点 name类型为字符类型，所以叫字符型注入点。这一类的 SQL 语句原型大概为 select from 表名 where name=‘admin’。注意多了引号。组合出来的sql注入语句为：select from news where chr=‘admin’ and 1=1 ’ ’ 闭合单引号chr=‘admin’ union select 1,2,3,4 and ‘1’='1 chr=‘admin’(闭合前面单引号) union select 1,2,3,4 and ‘1’=‘1’

（3）搜索型注入点
这是一类特殊的注入类型。这类注入主要是指在进行数据搜索时没过滤搜索参数，一般在链接地址中有“keyword=关键字”，有的不显示在的链接地址里面，而是直接通过搜索框表单提交。此类注入点提交的 SQL 语句，其原形大致为：select * from 表名 where 字段 like ‘%关键字%’。 组合出来的sql注入语句为：select * from news where search like ‘%测试 %’ and ‘%1%’=’%1%’ 测试%’ union select 1,2,3,4 and ‘%’=’

（4）GET 注入
提交数据的方式是 GET , 注入点的位置在 GET 参数部分。比如有这样的一个链接http://xxx.com/news.php?id=1， id 是注入点。

（5）POST 注入 使用 POST 方式提交数据，注入点位置在 POST 数据部分，常发生在表单中。

（6）Cookie 注入 HTTP请求的时候会带上客户端的 Cookie, 注入点存在 Cookie 当中的某个字段中。

（7）HTTP 头部注入 注入点在 HTTP请求头部的某个字段中。比如存在 User-Agent 字段中。严格讲的话，Cookie 其实应该也是算头部注入的一种形式。因为在 HTTP请求的时候，Cookie 是头部的一个字段。

漏洞修复方案

解决SQL注入问题的关键是对所有可能来自用户输入的数据进行严格的检查、对数据库配置使用最小权限原则。 通常使用的方案有：

（1）所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前几乎所有的数据库系统都提供了参数化SQL语句执行接口，使用此接口可以非常有效的防止SQL注入攻击。
（2）对进入数据库的特殊字符（’"<>&*;等）进行转义处理，或编码转换。
（3）确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int型。
（4）数据长度应该严格规定，能在一定程度上防止比较长的SQL注入语句无法正确执行。
（5）网站每个数据层的编码统一，建议全部使用UTF-8编码，上下层编码不一致有可能导致一些过滤模型被绕过。
（6）严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。
（7）避免网站显示SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。
（8）在网站发布之前建议使用一些专业的SQL注入检测工具进行检测，及时修补这些SQL注入漏洞。

这篇关于漏洞系列之——SQL注入的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！