免责声明：文章只用于技术探讨，严厉抵制在网络搞破坏行为。
在学习Web漏洞的过程中，就一直有一个强烈的想法，试着总结一下学习的内容，另外参考了一些SQL注入漏洞挖掘实践和自身体会，寻思着写一篇思路总结。这篇文章会不断的更新，随着实践的继续和各位的指点批评会不断完善思路。
SQL注入漏洞的知识体系
一. 数据库注入：access mysql mssql oracle mongodb postgresql
不同数据库在注入上是由差异，比如：SQL语句不同，数据库的权限不一样。尤其是第二者，不同的权限衍生的思路是不一样的，有高权限和低权限之分。还有和数据库自身的配置有关。
二. 数据类型注入： 数字型 字符型 搜索型 加密型(base64 json)
在测试注入点时我们首先需要解决的问题就是数据类型，才能进一步测试注入点是否存在。
三. 提交方式注入： get post cookie http 头
提交方式决定了我们测试的注入点。一般常见的是 Get , POST 但是实际上Cookie，UA都有可能存在注入点。
四. 注入手段：堆叠，联合，报错，布尔，延时，二次注入，宽字节注入，DNS注入
网站对于SQL注入也是有防护的，我们需要采取一些手段进行绕过，以及解决一些数据不会显的问题。
溯本求源
基本的概念最能说明事物的本质，但我们将其忽略，实际上这些基本概念往往决定我们的思路。
在
数据交互
中，
前端的数据传入到后台处理
时，
没有做严格的判断
，导致其传入的“数据”
拼接
到SQL语句中后，
被当作SQL语句的一部分执行
。 从而导致数据库受损（被脱裤、被删除、甚至整个服务器权限沦陷）。简而言之就是,由于用户不可控输入，攻击者可以任意的输入恶意的sql语句，使原始的查询语句的语义发生改变。从而对数据库或操作系统产生风险。
我们可以得到的信息：
- 用户输入的数据不可信
- SQL注入原理：黑客的payload没有经过严格检查直接拼接SQL语句后直接带入数据库执行
- SQL注入漏洞经常出现的位置：往往是一些前后端数据交互的位置，如：可以进行增删改查以及一些接口的位置。
这段信息阐述了SQL注入漏洞的原理，并且为我们寻找SQL注入漏洞提供了思路。
实战中如何寻找SQL注入漏洞
观察网页同时使用BurpSuite进行抓包，关注数据包里的参数位置，尝试修改之后，如果网页发生了变化，就很可能是这个参数被带入到数据库查询了，那么就可能存在注入点。
SQL注入点一般存在于搜索框，登录页面、查找页面或添加页面等用户可以查找或修改数据的地方。因为这里的参数值往往可能是带入了数据库查询。
我一般
习惯根据功能点，看看参数的值，如果觉得这个参数可能会带入数据库查询，就很有可能存在SQL注入
，直接上手SQLMap跑一下，即使不是也没损失。
其实更多还是依据实践的经验，多看看一些挖洞的文章，看看他们的姿势，结合这个本质去理解，大量积累经验才能准确的测试SQL注入漏洞。
如何测试是否存在注入点
这一步是为了测试这个位置是否存在注入点，根据原理，如果存在SQL注入漏洞，这个位置首先会被带入查询数据库，而且这个位置对恶意字符过滤不严格。
经典的单引号，因为单引号会和数字型，字符串型冲突，如果返回结果为false，就说明未被过滤，而且还被带入了数据库，即是一个注入点。
还有一些如： and 1=1 或者 and 1=2 的方法，都是这个道理。
这一步的测试需要结合数据类型，还要考虑到引号闭合的问题。
ROOT && 非ROOT
ROOT权限测试思路
可以拿MySQL举例：每个数据库都有一个用户管理，存在一个超级账户可以管理所有的数据库。
因为在代码层面上，数据库链接时设置了使用用户，这个用户的权限决定了我们的战果上限。
- 非ROOT用户：如果这个用户只是个普通用户，那么你最多只能拿下当前的数据库。
- ROOT用户：你可以进行文件读写操作，跨库查询注入等操作
MySQL && ACCESS
MYSQL5.0以上版本：自带的数据库 名为information_schema
information_schema：存储数据库下的数据库名及表名，列名信息的数据库，因为这个特性的存在，我们可以通过查询这个数据来获取表名和字段名。
-
information_schema：存储数据库下的数据库名及表名，列名信息的数据库
-
information_schema.tables：记录表名信息的表
-
information_schema.columns：记录列名信息表
ACCESS数据库
因为ACCESS的数据库是只有一个库，库下面有多个表，我们需要拿到有利用价值的表。
这里需要猜解表名，猜解字段。你可以使用字典扫描，也可以使用偏移注入。
这里仅拿出两个数据库进行举例，其它的数据库都有各自的特点，在手工注入时要因地制宜采取测略。
思考常见几种注入方式
堆叠注入：多条语句使用;隔开，基本见不到，因为这意味着网站几乎没有防护。
联合查询注入：限制条件是必须要有回显
报错注入：是sql语句的错误信息会返回给前端，这里需要有源代码中存在这条代码才行
布尔盲注：这里的网页的没有回显，但是会根据你的sql语句有true和false两种状态，常见的是网页存在于消失，可以通过状态码，网页的显示来判断
延时盲注：限制几乎没有，只需要检测数据包发出到返回间隔即可，当然因为网络因素，可能存在些许误差。
宽字节注入：适用面不广泛，与其说是注入的手法，不如说是绕过过滤的手段。
实战中测试思路
实战中并不需要我们手测，因为当今的一些工具已经很成熟了，比如SQLMap等。
所以实战中，我们主要是要找可能存在SQL注入的位置，可以简单测试一下有没有，也可以完全不测试，直接丢进SQLMap跑一跑就知道有没有。
但是并不意味着注入原理不重要，还是需要学会原理的。
SQLMap使用可以参考我得另外一篇博客：
SQLMap使用教程：从入门到入狱详细指南_貌美不及玲珑心，贤妻扶我青云志的博客-CSDN博客
也有一些别的工具也很不错，如AWVS，goby等。
之后有时间的会更新一些注入原理，手工注入等一些细节的文章。
SQL注入漏洞总结到此结束，希望路过便朋友可以的话请指点一下，或者留下你们的思考和感悟。欢迎大家在我的评论区留言。
最后的话，创作不易，求各位大佬点个赞！！！