SQL Inject(SQL注入)概述

     在owasp发布的top10排行榜里，注入漏洞一直是危害排名第一的漏洞，其中注入漏洞里面首当其冲的就是数据库注入漏洞。

数据库注入漏洞,主要是开发人员在构建代码时, 没有对输入边界进行安全考虑,导致攻击者可以通过合法的输入点提交一些精心构造的语句,从而欺骗后台数据库对其进行执行,导致数据库信息泄漏的一-种漏洞。
一个严重的SQL注入漏洞，可能会直接导致一家公司破产！
SQL注入漏洞主要形成的原因是在数据交互中，前端的数据传入到后台处理时，没有做严格的判断，导致其传入的“数据”拼接到SQL语句中后，被当作SQL语句的一部分执行。 从而导致数据库受损（被脱裤、被删除、甚至整个服务器权限沦陷）。

SQL inject漏洞攻击流程

第一步：注入点探测

自动方式：通过web漏洞扫描工具，自动进行注入点发现

手动方式：手工构造sql inject测试语句进行注入点发现

第二步：信息获取

通过注入点取期望得到的数据

1. 环境信息：  　　数据库类型，数据库版本、操作系统版本、用户信息等
2. 数据库信息：　  数据库名称、数据库表、表字段，字段内容（加密内容破解）

第三步：获取权限

获取操作系统权限：通过数据库执行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输入提交，可以看到用户信息都被遍历出来了

Web安全之SQL Inject

原文：https://www.cnblogs.com/DxyG/p/13466598.html