新手小白入门——SQL注入之提交方式（即数据位置）分类

此文是对上一篇文章（新手小白入门——SQL注入之数据位分类）的补充！！！上一篇文章主要针对不同提交方式（请求）如何取数据进行详细说明，而本篇文章主要针对不同提交方式（请求）中的SQL注入进行介绍！

在进入正题前，我们再来学习一下如何判断是否存在SQL注入或者说如何判断是否存在SQL注入点

1.基于错误信息判断SQL注入点

①单引号引起的错误
当在用户输入框中输入一个单引号（'），如果页面返回数据库错误信息，如“Error: You have an error in your SQL syntax: check the manual that corresponds to your MySQL version for the right syntax to use near '' at line 1”
这表明输入的单引号破坏了SQL语句的语法结构，而且用户输入的内容直接被嵌入到了SQL语句中，这个用户输入框很可能是一个SQL注入点。
②引号不匹配错误
若在输入框中输入“'or 1=1”，可能返回类似“Error: You have an error in your SQL syntax: check the manual that corresponds to your MySQL version for the right syntax to use near ''OR 1=1' at line 1”的错误。
这种错误表明输入的内容导致了SQL语句的语法不匹配，再次表明用户输入的内容参与了SQL语句的构建，也提示此处可能是一个SQL注入点。
③关键字错误（这种还没遇到过，等遇到时会再举例详细说明）
输入“SELECT * FROM users WHERE username = 'admin'; DROP TABLE users;-- ”若返回“Error: You can't specify target table 'users' for update in FROM clause”这类的错误。
这表明输入的SQL关键字（如这里的“DROP TABLE”）被当作SQL语句的一部分执行，虽然没有成功，但是表明存在SQL注入漏洞，这个注入点就是一个潜在的注入点。

2.检查HTTP请求
查看发送到服务器的HTTP请求中的参数部分，特别是那些可能用于数据库查询的参数，如果这些参数没有经过严格的过滤和验证，就有可能是注入点。例如，一个用户登录的POST请求，其中的用户名和密码字段如果直接用于构造SQL语句，就需要重点关注。

3.利用逻辑判断
尝试输入“OR 1=1”或者“AND 1=2”这种带有逻辑判断的语句，若输入“OR 1=1”后，页面返回的结果和正常情况不同（例如正常查询需要账号密码正确才返回信息，输入这个后返回所有信息），或者输入“AND 1=2”页面显示为空，但正常情况不是这样，那就可能存在注入点。
4.时间延迟测试（这种也还没遇到过，等遇到时会再举例详细说明）
对于支持时间函数（如SLEEP）的数据库，可以在输入框中输入类似“SLEEP(5)”的内容，如果页面响应延迟了5秒，就很有可能存在SQL注入点，因为这表明输入的时间延迟函数被数据库执行了。

下面我们进入正题！

一、get请求（请求行位置）

get请求中的SQL注入的原理：

 get请求会将参数通过URL传递，在上篇文章中我们已经简单介绍过查询参数。当服务器端使用这些参数构建SQL查询语句时，如果没有对输入的参数进行足够的安全验证和过滤就直接拼接，就可能导致SQL注入。

1.基于get请求的搜索型注入

在这里以用户名为vince为例，如下图：经过抓包后得到的页面渲染效果：

2.基于get请求的字符型注入

在这里仍然以用户名为vince为例

3.基于get请求的xx型注入

以上三种基于get请求的注入均可通过修改查询参数（图片上面写错了），从而构建错误的SQL查询语句，进而达到 SQL注入

在这里，我以基于get请求的字符型注入为例来详细说明其注入

仍然以用户名为vince为例，抓包后，我将查询参数进行了修改：由vince改为vince'or1=1(不添加注释符#是因为在抓取的数据包中修改若添加注释符#会后面的数据内容失效，发送后页面渲染的效果会报错，如下面第一张图所示），将它发送经过页面渲染的效果如下面第二张图所示

由此可以看出利用查询参数可以进行SQL注入，此处存在注入点！

 二、post请求（请求体位置）

post请求中的SQL注入的原理：

POST请求的数据是放在请求体（Request Body）中发送给服务器的。当服务器端接收这些数据后，如果没有对POST数据进行安全的处理，直接将其用于构建SQL语句，就可能导致SQL注入。

主要是基于post请求的数字型注入

当将id=1改为id=1 or 1=1(由于数字型注入不需要考虑引号闭合问题，所以这里和字符型注入测试时的测试语句不同），抓包后经过页面渲染的效果如下：展现出来有关的所有信息！

解释：由于在id=1 or 1=1这个测试语句中‘or'后面的‘1=1’条件恒为真，不论前面的数字是1还是其他，都会显示出相关的所有用户信息！！！(如下图所示），那么说明此处可以进行SQL注入！

三、cookie(请求头位置）

原理：

通过篡改Cookie内容，插入SQL语句片段，使得查询条件被篡改，从而达成SQL注入，这可能会返回本不该返回的大量用户信息，甚至获取管理员权限，对数据库进行恶意操作。

eg:在这里以pikachu靶场中的http header注入为例：将admin 修改为 admin or 1=1#（如下图所示）

将admin 修改为 admin‘ or 1=1#后抓包并放到重放器里面进行页面渲染后的效果如上图所示，在这里可能是pikachu靶场版本的问题（正常的效果应该如下图所示为登陆页面）如果你的页面经测试出来也是和我一样的效果，那么在这里我们只需知道此处存在SQL注入，无需过度纠结

以上是个人在学习过程中的总结，如有错误，欢迎大家前来评论指正哦！