1.1 SQL注入漏洞
SQL注入漏洞可以说是已经是一个历史漏洞了，早在15年的阿里峰会上，长亭科技的陈宇森就进行了名为《永别了SQL注入》的演讲，但作为最常见也是大家接触最多的漏洞，我们还是决定写出来，供大家学习。
漏洞描述
SQL注入是网站存在最多也是最简单的漏洞，主要原因是程序员在设计程序时，忽略了对输入字符串中夹带的SQL指令的检查，被数据库误认为是正常的SQL指令而运行，从而使数据库受到攻击，可能导致数据被窃取、更改、删除，以及进一步导致网站被嵌入恶意代码、被植入后门程序等危害。
我们一般的进行网站访问可以称为正常的web端口访问
SQL注入是如何访问？
（1）SQL注入也是正常的web端口访问
（2）只是传入的参数值并非是程序设计者所希望的，而是传入了嵌套SQL代码的参数值
（3）参数值利用程序处理注入者的逻辑，按注入者的期望执行数据库查询
（4）甚至页面呈现按SQL注入者期望显示
通常情况下，SQL注入的位置包括
表单提交，主要是POST请求，也包括GET请求；
URL参数提交，主要为GET请求参数；
Cookie参数提交；
HTTP请求头部的一些可修改的值，比如Referer、User_Agent等；
一些边缘的输入点，比如.mp3文件的一些文件信息等。
……
漏洞等级
高危
漏洞危害
SQL注入的危害不仅体现在数据库层面上，还有可能危及承载数据库的操作系统；如果SQL注入被用来挂马，还可能用来传播恶意软件等，这些危害包括但不局限于：
（1）数据库信息泄漏：数据库中存放的用户的隐私信息的泄露。作为数据的存储中心，数据库里往往保存着各类的隐私信息，SQL注入攻击能导致这些隐私信息透明于攻击者。
（2）网页篡改：通过操作数据库对特定网页进行篡改。
（3）网站被挂马，传播恶意软件：修改数据库一些字段的值，嵌入网马链接，进行挂马攻击。
（4）数据库被恶意操作：数据库服务器被攻击，数据库的系统管理员帐户被篡改。
（5）服务器被远程控制，被安装后门。经由数据库服务器提供的操作系统支持，让黑客得以修改或控制操作系统。
（6）破坏硬盘数据，瘫痪全系统。
漏洞检测方法
可以使用：
%5c，单引号，双引号，反斜杠，负数， 特殊字符，and，or，xor探测是否存在注 入！
注释符# +交替用，一个不行，就另一个 （一定要在注释符号后加空格，或者URL编码后的空格（%20），否则注释符号 不会产生作用）
1、先判断是数字型还是字符型，如果判断不出来跳到9
2、接着判断有没有括号
3、后面跟上+注释符
4、order by判断字段数，如果没法判断，则直接union select 1,2,3一个个测试过去
5、如果返回的页面发生变化，则联合查询
6、如果union select 1,version(),3返回的页面没有发生变化，即联合查询失败，则尝试报错 注入
7、如果报错注入页面也没有把信息显示出来，则延时注入
8、如果延时注入也不行，则导入导出
9、尝试延时注入，如果从1过来的，则三种情况，直接跟payload，参数后面加单引号或者 双引号
漏洞利用方法
注入点分类：
按照注入点类型来分类
（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 '%'='
按照数据提交的方式来分类 （1）GET 注入
提交数据的方式是 GET , 注入点的位置在 GET 参数部分。比如有这样的一个链接http://xxx.com/news.php?id=1 , id 是注入点。
（2）POST 注入
使用 POST 方式提交数据，注入点位置在 POST 数据部分，常发生在表单中。
（3）Cookie 注入
HTTP 请求的时候会带上客户端的 Cookie, 注入点存在 Cookie 当中的某个字段中。
（4）HTTP 头部注入
注入点在 HTTP 请求头部的某个字段中。比如存在 User-Agent 字段中。严格讲的话，Cookie 其实应该也是算头部注入的一种形式。因为在 HTTP 请求的时候，Cookie 是头部的一个字段。
按照执行效果来分类
（1）基于布尔的盲注，即可以根据返回页面判断条件真假的注入。
（2）基于时间的盲注，即不能根据页面返回内容判断任何信息，用条件语句查看时间延迟语句是否执行（即页面返回时间是否增加）来判断。
（3）基于报错注入，即页面会返回错误信息，或者把注入的语句的结果直接返回在页面中。
（4）联合查询注入，可以使用union的情况下的注入。
（5）堆查询注入，可以同时执行多条语句的执行时的注入。
下文将会对这些知识点进行简单介绍，并对并穿插以下waf绕过姿势等
漏洞修复方案
解决SQL注入问题的关键是对所有可能来自用户输入的数据进行严格的检查、对数据库配置使用最小权限原则。 通常使用的方案有：
（1）所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。当前几乎所有的数据库系统都提供了参数化SQL语句执行接口，使用此接口可以非常有效的防止SQL注入攻击。
（2）对进入数据库的特殊字符（'"\<>&*;等）进行转义处理，或编码转换。
（3）确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int型。
（4）数据长度应该严格规定，能在一定程度上防止比较长的SQL注入语句无法正确执行。
（5）网站每个数据层的编码统一，建议全部使用UTF-8编码，上下层编码不一致有可能导致一些过滤模型被绕过。
（6）严格限制网站用户的数据库的操作权限，给此用户提供仅仅能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。
（7）避免网站显示SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。
（8）在网站发布之前建议使用一些专业的SQL注入检测工具进行检测，及时修补这些SQL注入漏洞。
漏洞案例
网络安全实验室注入关
sqlilabs
btslab
webug
webgoa
Owasp Broken Web Application Project
Last updated