SQL Injection | SQL 注入 —— 数据提交方式
关注这个漏洞的其他相关笔记：SQL 注入漏洞 - 学习手册-CSDN博客
0x01：服务端获取数据的方式
本章中，我们将以 PHP 语言为例，深入探讨服务器后端通过接收数据包能够获得的信息，并着重分析这些信息如何成为 SQL 注入攻击的潜在攻击点。
0x0101：概念引入 - PHP 超全局变量
PHP 作为一款后端语言，其中预定义了许多的 “超全局” 变量，这些变量可以在一个脚本的全部作用域中使用，下面介绍一些常见的 PHP 服务端中用于接收客户端信息的超全局变量：
$_GET # 存放 GET 方式提交的数据$_POST # 存放 POST 方式提交的数据$_REQUEST # 获取 GET/POST 方式提交的数据$_COOKIE # 获取请求头中 COOKIE 字段提交的数据$_SERVER # 包含了诸如头部信息（header）、路径（path）、以及脚本位置（script locations）等等信息的数组。以下是一个示例，来展示上面这些超全局变量中所接收的内容（这些可都是后端可能用到的内容呀，也就是我们的注入点）：
<!-- FileName: GetClientValue.php --><?php// 为访问当前页面的客户设置一个 Cookiesetcookie("user", "Blue17", time() + 60 * 60);// 按照设置的格式打印对应的值function print_value($key ,$value) {echo "<h3 align='center'>" . $key . " Value</h3>";var_dump($value);echo "<hr>";}print_value('$_GET', $_GET); // 打印 $_GET 中的内容print_value('$_POST', $_POST); // 打印 $_POST 中的内容print_value('$_REQUEST', $_REQUEST); // 打印 $_REQUEST 中的内容print_value('$_COOKIE', $_COOKIE); // 打印 $_COOKIE 中的内容print_value('$_SERVER', $_SERVER); // 打印 $_SERVER 中的内容?> 
0x02：SQL 注入 —— 常见注入点
0x0201：GET 方式注入
特点：传输的数据都会在 URL 中显示。
GET 方式注入的方式比较常见，主要是通过 URL 来将数据传输到后台，再带到数据库中执行，可以利用联合注入方式进行尝试性的注入。
0x0202：POST 方式注入
特点：POST 型的注入点主要出现在页面表单的提交，比如登录框的注入。
此种注入点可以利用 BurpSuite 抓包进行重放修改包中的内容，来尝试性的进行注入，和 GET 型的区别是需要借助抓包工具进行测试，返回的结果主要为代码，也可以转换为网页来显示。
0x0203：REQUEST 方式注入
REQUEST 方式能够同时接收 GET 型和 POST 型的客户传参，测试的大体流程与前面两者一样，要么从 URL 中尝试进行注入，要么通过 BurpSuite 进行抓包，来从 POST 请求体中尝试找到注入点。
这里多一嘴，$_REQUEST 能同时接收 GET 型和 POST 型的客户传参，但是我是不是用 $_GET 和 $_POST 分别接收同一个参数也能实现 $_REQUEST 的作用呢：
<?php// 通过 $_GET 和 $_POST 模拟 $_REQUEST 的作用$name = $_GET['name'];if (empty($name)) {$name = $_POST['name'];}var_dump($name);然后恰巧，过滤的时候，只过滤了 $_GET 传递过来的内容，然后针对 $_POST 传递过来的内容没有做过滤，是不是就产生了 SQL 注入漏洞了（只是假设，我猜没人这么傻会这么写）。
0x0204：HTTP Header 注入
HTTP 头部注入问题通常源于服务端需要解析 HTTP 请求头以验证客户端身份或获取客户端信息。在某些情况下，这些信息可能与其他关键数据一起被存储到数据库中，并在前端显示。然而，如果服务端未能对这些信息进行适当的处理，就可能导致 SQL 注入漏洞的出现。简而言之，未经严格验证的 HTTP 头部数据，若被不当处理，便可能成为安全漏洞的源头。
比如下面，就是我靶场中捕获的一个 HTTP 请求头：
服务端能从这个请求头中了解到我是谁（Cookie ），我从哪里来（Referer），我当前使用的浏览器型号（User-Agent）等信息。
以登录操作为例，一般在登录完成后，服务端会通过 Cookie 给我们传递一个登录凭证，后续我们只要携带这个 Cookie，它就会认为我们是处于登录状态。那么它为什么会认为我们处于登录状态呢？很有可能就是我们每次访问的时候，服务端都会将 Cookie 中的内容带入的数据库中进行比对，来验证我们是否是登录成功的用户。而我们挖掘 SQL 注入的核心就是，任何与数据库可能发生信息交换的地方，都有可能存在 SQL 注入漏洞！