以下内容均为个人学习总结，不喜勿喷，欢迎志同道合的小伙伴一同学习一同进步

所谓SQL注入就是用户在能够控制SQL查询、更新、插入、删除等语句的参数的情况下，攻击者通过构造特殊的输入字符串使后端程序错误地识别SQL查询语句中的代码与数据部分从而导致数据库管理系统输出了非预期的结果的一种行为。

SQL注入本质上来讲就是拼接字符串，通过输入额外的信息破坏外后端脚本原有的查询语句结构，从而达成注入的目的。 举个例子，后端后一段查询代码是下面样的：

当用户正常输入的时候：

后端的查询语句实际上是这样的：

但攻击者往往不会这样中规中矩，他们往往会构造这样的输入：

此时后端的查询语句变成：

此时攻击者就成功获取到了你的数据库名称。 通过上面的例子我们可以看出，攻击者构造的查询参数在SQL语句中没有被当作一个字符串对待，而是具有了实际的功能特性，这是PHP的语法决定的，它只是简单地将用户的输入与后端预定义的语句做了一个拼接，将拼接的结果整体作为一条SQL的查询语句。正是这个特性导致了SQL注入的产生，那么为了避免SQL注入，我们可以考虑的一点是不是可以想办法让PHP将用户输入的参数当作SQL语句的结构，而只作为参数呢？这就是预防SQL注入的另一个方向，PHP预编译技术，当然这个我们容后再讨论。

当我们传入的参数在后端代码中被引号引起来的时候，我们称这种情况为字符型注入

此时我们的参数$_GET['id']被单引号引起来了

此时我们的参数$_GET['id']被双引号引起来了，所以大家觉得哪个憨憨程序员会这么写呢？？所以双引号作为闭合符的情况基本上不可能出现。

我们传入的参数在后端代码中没有被引起来的时候，我们称这种情况为字符型注入。当然之后参数类型为数字的时候，才存在区分数字型和字符型的情况

此时我们传入的参数直接与id进行比较

所谓GET型注入，顾名思义，即注入点的参数是同通过GET请求发送到后端进行处理的。其又可以分为下面两种情形：

即注入点在url中。举个例子，现在有一个网页，实现了根据学生学号，来查询学生基本信息的功能，学生的id信息是通过GET方法传参发送到后端的，其请求的url如下

后台处理代码如下

在该例中，我们通过修改url中的id参数的值，来控制前端页面的显示结果。因为没有过滤的原因，我们输入的任何参数值都将被直接拼接到SQL查询语句中，那么我们就可以通过联合查询注入的方式进行注入。

简单理解就是注入点在请求头中。还是上面的例子，不过url中的参数被后端进行了严格的过滤，不存在任何的注入方法，但后端在进行处理的时候不仅仅是使用了查询语句，还对我们请求头中的user-agent字段在数据库中进行了查询，来防止恶意爬虫，但憨憨程序员却没有对用户的请求头做过滤。于是乎我们可以在请求头中构造恶意代码。后端处理逻辑如下：

可以看到后端代码中并没有对user-agent字段做过滤，那么我们就可以直接开始构造注入语句： 这里我们可以通过BurpSuite抓包来修改user-agent字段： 当然我们不能直接上来就构造联合查询注入，这一点后面再将，这里只是演示请求头注入的效果。 那么又有一个问题，我们怎么知道后端对user-agetn字段做了判断呢？没错，我们不知道，所以这就需要我们在可能的注入点挨个尝试？是不是有一种生无可恋的感觉，那么多注入点，得尝试到什么时候？这时候就得我们得注入神器sqlmap登场了。这个容后再说。

POST注入与GET注入不同的地方在于请求的参数是放在请求体中而不是在url中直接显示给用户的。那么我们怎么才能劫持并修改通过POST方法上传的参数呢？这时候就需要我们的渗透测试神器BUuripSuite登场了。正常POST请求信息如下： 我们注入之后的请求如下

这部分内容是sql注入的重点，不过在讲具体的注入方法前，我们先聊一下如何判断后端SQL语句中参数的闭合类型。

通常的，有三种闭合符和一些变种

以dvwa靶场为例，当我们输入以下内容的时候 按下确认键之后，返回MYSQL的报错信息提示如下 注意看箭头部分被引号引起来的部分''1111'''，最外侧一对引号是MYSQL错误信息包含的引号，我们把它直接剔除掉，于是有了'1111''，这部分就是我么SQL语句中报错的部分，可以看到出现了三个单引号，这样势必有一个单引号是多余的，于是触发了报错。这也就说明了，后端参数的闭合方式是通过单引号闭合的，也就是

因为我们传参的时候多输了一个单引号，于是后台语句变成了

很显然这是不符合mysql的语法规范的。 如果我们输入的是双引号，则不会报错，从而判断出，后台的闭合符类型为单引号。

如果后台的闭合符为双引号，即

那么我们输入参数?id=1111"时会报出错误信息You have an error ...... near '"1111""' at lint 1，同理输入?id=1111'的时候不会报错，于是判断后台闭合符为双引号。

除了上述两种字符型的闭合符外，还存在着数字型闭合，那么怎么判断是不是数字型闭合呢？

Method 1： 通过算数运算符 当我们传入下面的参数时，页面有正常的唯一回显

当输入

的时候会显示与id=1时不同的数据 那么如果后台为数字型闭合符，当我们输入

的时候，如果显示的结果与id=1的时候一致，则可以判断出来后端的闭合符为数字型。

Method 2： 通过注释符 当我们输入下面内容的时候

如果前端显示的结果与id=1的时候一样，那么后端的闭合符就为数字，当然还有一种情况就是后端对我们的输入进行了处理无论我们怎么输入都回显id=1的结果，此时这种判断方法就行不通了。

在上述三种闭合符类型的基础上，后端的闭合符可能还会出现如下的变种

对应的测试payload只需在上述三种闭合符payload的基础上对应得加上括号闭合即可，如：

information_schema库是mySQL自带的一个库，其中包含了当前数据库管理系统的所有信息，但该数据库并不是一个实体的数据库，它不存储任何实际意义上的数据，它只是整个数据库管理系统的一个视图，当某个数据库的某个表发生变化时，information_schema库中相关的数据将同时发生变化。 在注入中，我们关注的是该库中的schemata、tables、columns三个表。他们分别存储了整个数据库管理系统的所有数据库信息，表信息，字段信息。在schemata表中，通过schema_name字段可以获取所有的数据库名；在tables,通过table_name、table_schema字段可以获取所有的表名与其对应的数据库名；在columns表中，通过columns、table_name、table_schema字段可以获取所有的字段名以及其所属表与数据库。 我们的注入思路就是先通过mysql的内建函数database(),获取当前数据库名，再通过tables表获取，所有的表信息，再通过columns表获取上述表所有的字段，最后通过字段查询想要的数据。 当然使用information_schema库查询信息有一个很重要的条件限制，那就是，需要当前连接数据库的用户具有读该数据库的权限，

STEP1：判断闭合符 照前面所述方法进行判断 STEP2：判断列数 联合查询会将两条查询语句的查询结果拼接到一起返回！于是反映出联合查询需遵守的一个规则便是，两条查询语句的查询字段数必须相等，于是乎在利用联合查询进行注入的时候，我们第一步要做的就是判断判断后端代码中的SQL查询语句的字段数。我们有两种方法判断： Method 1： order by方法 order by 自己在SQL语句中是用来做排序的，标识根据哪一个字段进行排序，如：

表示根据username字段进行排序，当然也可以跟数字，标识根据表中的第几个字段进行排序，如：

就表示根据第四个字段进行排序，此时因为第四个字段不存在所以将报错显示 报错信息翻译过来就是：在order字段中存在未知的列。表示列数为4的字段不存在。 当我们输入

的时候，将正常显示，不会提示报错信息，两相比较得出查询语句的字段有3个。 所以我们可以构造这样的输入进行判断：

Method 2： 列数不匹配报错 输入如下语句

因为第四个字段不存在的原因，会报错 当输入

此时，将正常显示查询结果。故判断首条查询语句包含3个字段。 STEP 3：查数据库名

注意id=-1,此处id的值必须是一个在数据库中id字段不存在的值，否则联合查询第一条语句的查询结果将占据显示位，我们需要的第二条查询语句的查询结果就不能正常显示到浏览器中。 STEP 4：查表名 假如上一步查询出来的数据库名为security

注意第二条查询语句我们payload插入位置的字段一定要在前端有回显，否则我们将不能查看到查询结果。 group_concat(fileds)函数表示查询结果中的多条纪录合并为一行显示，默认使用逗号分隔。为什么非得显示在一行里面呢？因为，超过两行的数据有可能不会显示在浏览器中。 这一步还可以换一种写法，从而省略掉第3步

差异自寻！！！！！！！ STEP 5：查列名 假如上一步查询出来的表名中有user表

STEP 6：查数据 假如上一步查询出来的字段有username与passwd

concat函数将每一条记录的每一个字段拼接成一个字符串，0x7e表示~，作为一个分割符出现 concat_ws函数与concat函数功能相似，不过它的第一个参数将作为分隔符出现在查询结果中。 limit 0,1的第一个参数表示从第一条记录开始，1表示向下查找一条记录，故limit 0,1表示第一条记录。group_concat函数将把所有的记录拼接成一个一条记录返回，limit 0,1只能逐条返回数据

盲注又分为布尔盲注与时间盲注两种类型

基本原理是：通过控制通过and连接起来的子句的布尔值，来控制页面的显示结果来判断and后子句的真实性。举个例子

根据and的特性，当and运算符左边的计算结果为真时会继续判断后边的运算结果，如果右边的结果也为真则整个语句为真，当右边的语句为假时，则整个语句为假；当and左边的运算结果为假时，则直接判断整个语句为假，举例如下

利用and的这个特性，id=1恒为真的时候，and右边substring子句的执行结果将直接影响这个SQL查询语句的结果，即substring子句为真，整个查询语句为真，页面正常回显内容，当substring子句为假的时候，整个查询语句为假，页面不正常回显内容。 在上面我们构造的查询语句中，对数据库名的第一个字段进行了判断，假如判断正确，那么接着对第二个字符进行判断

直到数据库名的最后一个字符被找出来。可以看到这个过程耗时耗力，我们要对所有可能的大小写字母、数字、特殊字符进行枚举，所以可以考虑透过自动化脚本的方式来进行判断。 要获取表名、字段名、数据，只需将上述database()替换为对应payload即可，如要获取表名

时间盲注与布尔盲注有异曲同工之妙，只不过判断语句正确与否的标志不再是查询结果有没有被正确得回显，而是网页的响应时间。看下面语句: