SQL Inject(SQL注入)概述
在owasp发布的top10排行榜里，注入漏洞一直是危害排名第一的漏洞，其中注入漏洞里面首当其冲的就是数据库注入漏洞。
数据库注入漏洞,主要是开发人员在构建代码时, 没有对输入边界进行安全考虑,导致攻击者可以通过合法的输入点提交一些精心构造的语句,从而欺骗后台数据库对其进行执行,导致数据库信息泄漏的一-种漏洞。
一个严重的SQL注入漏洞，可能会直接导致一家公司破产！
SQL注入漏洞主要形成的原因是在数据交互中，前端的数据传入到后台处理时，没有做严格的判断，导致其传入的“数据”拼接到SQL语句中后，被当作SQL语句的一部分执行。
从而导致数据库受损（被脱裤、被删除、甚至整个服务器权限沦陷）。
SQL inject漏洞攻击流程
第一步：注入点探测
自动方式：通过web漏洞扫描工具，自动进行注入点发现
手动方式：手工构造sql inject测试语句进行注入点发现
第二步：信息获取
通过注入点取期望得到的数据
- 环境信息： 数据库类型，数据库版本、操作系统版本、用户信息等
- 数据库信息： 数据库名称、数据库表、表字段，字段内容（加密内容破解）
第三步：获取权限
获取操作系统权限：通过数据库执行shell，上传木马
SQL inject漏洞-常见注入点类型
- 数字型 user_id=$id
- 字符型 user_id=‘$id‘
- 搜索型 text LIKE ‘%{$_GET[‘‘search]}%‘
数字型注入（post）演示
打开pikachu的SQL-inject中的数字型注入 ，页面中的查询，在查询相应的用户之后会返回用户名和用户邮箱
点击查询之后可以发现是以post方式提交的，并没有在url中进行传参，接着我们打开burp找到刚提交的post请求发送到Repeater
然后把id修改为我们所猜想的数据库逻辑构造出的payload id=3 or 1=1 ，点击GO，然后直接查看Render页面上面返回的结果
可以看到页面把数据库内所有的用户数据都给显示出来了，意味着id查询处是存在数字型SQL注入漏洞
通过查看后端代码，可以发现漏洞形成的原因，后端从前端获取到id赋值给$id之后没有做任何处理就直接拼接到SQL里，这样就导致了$id可以被直接控制，并且可以通过拼接构造合法的SQL语句造成信息的泄漏。
字符型注入（get）演示
打开pikachu上SQL-inject的字符型注入，输入用户名，页面会返回相应的用户id和用户邮箱
随意输入一段字符，页面会返回用户不存在，而且参数是在url里面提交的，是一个get请求
然后我们根据页面的反馈来猜想后台的执行语句来构造合法的payload，我们输入的一段字符，后台的执行语句应该是一段数据库字符查询语句
我们可以先用一个单引号闭合掉前面的单引号，然后用#符号注释掉后面的单引号，中间是一个恒成立的条件，这样我们的payload就是 lucy‘ or 1=1# 将这段payload输入点击提交
接着来看后端代码，与数字型大同小异，唯一区别在于$name的单引号处理
搜索型注入演示
搜索型就是用的数据库中的搜索语句来进行的查找，它会搜索所有包含你所输入部分的结果
我们可以根据数据库的搜索语句 select * from member where username like ‘%l%‘; 来构造合法的闭合 l%‘ or 1=1#
接着我们用这个payload来测试SQL注入漏洞，将payload提交后可以看到页面显示出了所有的用户信息
接着查看后台代码，和之前两种类型一样，都是没做任何处理就直接拼接到了SQL中，唯一的区别是变量拼接时用了单引号百分号处理
XX型注入演示
打开xx型注入，先输入一个单引号提交，页面报错
查看源码，发现XX型在参数拼接使用了一个()，我们可以根据这一点来构造合法的闭合
我们根据猜想构造payload xxx‘) or 1=1# ，将payload输入提交，可以看到用户信息都被遍历出来了