【新手初步了解】SQL注入按不同方式的分类

一、按照提交方式分类

（一）get提交（按照请求方式划分）

1.取数据

$_GET（不是针对get请求，也就是不是取get请求携带的数据，而是取得查询参数数据）

对于post请求（只要url上面有携带查询参数的）也是可以的，如下是携带查询参数的post请求

（注意：post请求也是可以携带查询参数的，post改成get也是可以取得查询参数的。）

• 2.GET 请求中的 SQL 注入原理

  • 在 GET 请求中，用户输入的数据通过 URL 参数传递给服务器。例如，一个典型的 GET 请求 URL 可能是http://example.com/products.php?id=1，其中id=1是参数部分。当服务器端脚本（如 PHP、ASP 等）使用这个参数来构建 SQL 查询语句时，如果没有对参数进行正确的过滤和验证，就可能发生 SQL 注入。
  • 假设服务器端有一个查询产品信息的 SQL 语句如下：

SELECT * FROM products WHERE product_id = [从GET请求获取的id参数];

攻击者可以通过修改 URL 中的参数值来注入 SQL 语句。比如，将id=1修改为id=1; DROP TABLE products;，这样当服务器执行这个 SQL 查询时，就会先查询product_id = 1的产品信息，然后执行DROP TABLE products语句，导致products表被删除。

• 3.常见的 GET 请求 SQL 注入类型

  • 3.1数字型注入：

    • 当 GET 请求中的参数是数字类型时，攻击者可以利用数字比较操作进行注入。例如，在上述产品查询的例子中，如果产品 ID 是数字，攻击者可以输入id=5 OR 1 = 1。修改后的 SQL 语句变为：

SELECT * FROM products WHERE product_id = 5 OR 1 = 1;

因为1 = 1恒为真，通过OR连接后，这个查询将返回所有产品的信息，而不仅仅是产品 ID 为 5 的商品，从而绕过了原有的基于产品 ID 的查询限制。

• 3.2字符型注入：

  • 当参数是字符串类型时，攻击者需要考虑引号的闭合。例如，一个根据产品名称查询产品的 SQL 语句可能是：

SELECT * FROM products WHERE product_name = '[从GET请求获取的产品名称参数]';

攻击者可以输入product_name=%27 OR %271%27=%271（URL 编码后的' OR '1'='1），此时 SQL 语句变为：

SELECT * FROM products WHERE product_name = '' OR '1'='1';

同样，因为'1'='1'恒为真，且通过OR连接，使得整个查询条件恒成立，攻击者可以获取到所有产品的信息。

• 3.GET 请求 SQL 注入的危害

  • 数据泄露：攻击者可以获取存储在数据库中的敏感信息，如用户账户信息、产品详情、订单信息等。例如，通过注入查询语句获取用户表中的用户名和密码，可能会导致用户账户被盗用。
  • 数据篡改：能够修改或删除数据库中的数据。例如，修改产品价格、用户订单状态等，这会对业务的正常运营造成严重影响。
  • 数据库结构破坏：执行诸如DROP TABLE或ALTER TABLE等命令来破坏数据库的结构，导致整个应用程序无法正常运行，造成服务中断。

• 4.防范 GET 请求 SQL 注入的方法

  • 输入验证：
    • 对 GET 请求中的所有参数进行严格的验证，检查其是否符合预期的类型和格式。例如，对于数字参数，验证是否为数字；对于字符串参数，检查长度、字符范围等。
    • 可以使用正则表达式来验证参数。例如，验证一个数字参数是否为正整数可以使用正则表达式^\d+$。
  • 参数化查询（预处理语句）：
    • 使用参数化查询技术，将参数与 SQL 命令分开处理。例如，在 PHP 中使用 PDO（PHP Data Objects）的参数化查询：

$pdo = new PDO('mysql:host=localhost;dbname=test', 'username', 'password');
$stmt = $pdo->prepare("SELECT * FROM products WHERE product_id = :id");
$id = 1; // 假设这是从GET请求获取并经过验证的参数
$stmt->bindParam(':id', $id, PDO::PARAM_INT);
$stmt->execute();
$results = $stmt->fetchAll(PDO::FETCH_ASSOC);

这样，即使攻击者试图在参数中注入 SQL 语句，也不会被执行，因为参数被视为纯粹的数据，而不是 SQL 命令的一部分。

• 输出编码：
  • 当将从数据库中获取的数据显示在网页等前端界面时，对数据进行适当的编码，如 HTML 编码，以防止跨站脚本攻击（XSS）等其他安全问题。虽然这主要是针对 XSS 的防范措施，但在防范 SQL 注入后的后续安全问题上也有一定作用。

（二）post提交（按照请求方式划分）

1.取数据

用 $_POST就是针对post请求，取的是post数据

• 2.POST 请求中的 SQL 注入原理

  • POST 请求通常用于向服务器提交表单数据。这些数据在请求体中发送，而不像 GET 请求那样数据在 URL 中可见。例如，一个用户登录表单通过 POST 请求提交用户名和密码到服务器端脚本进行验证。当服务器端处理 POST 请求数据时，如果直接将这些数据用于构建 SQL 查询，且没有对其进行适当的安全处理，就会存在 SQL 注入漏洞。
  • 假设服务器端有一个验证用户登录的 SQL 语句如下：

SELECT * FROM users WHERE username = '[从POST请求获取的用户名]' AND password = '[从POST请求获取的密码]';

攻击者可以在 POST 请求的数据中注入恶意 SQL 语句。例如，在用户名字段中输入' OR '1'='1，密码字段随意输入，此时 SQL 语句变为：

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '[随意输入的密码]';

因为'1'='1'恒为真，且通过OR连接，整个查询条件恒成立，攻击者就可能绕过正常的登录验证，获取用户权限，访问受保护的资源。

• 3.常见的 POST 请求 SQL 注入类型

  • 字符型注入：

    • 这是 POST 请求中最常见的注入类型，因为表单数据通常是字符串类型。与前面登录验证的例子类似，攻击者通过闭合字符串引号并添加额外的 SQL 逻辑来进行注入。
    • 例如，在一个用户注册表单中，插入用户信息的 SQL 语句可能是：

INSERT INTO users (username, password, email) VALUES ('[从POST请求获取的用户名]', '[从POST请求获取的密码]', '[从POST请求获取的邮箱]');

攻击者可以在用户名字段中输入'); DROP TABLE users; --，此时 SQL 语句变为：

INSERT INTO users (username, password, email) VALUES ('); DROP TABLE users; --', '[从POST请求获取的密码]', '[从POST请求获取的邮箱]');

这可能会导致users表被删除，造成数据丢失和系统功能异常。

• 盲注（基于 POST 请求）：

  • 当服务器对 SQL 错误进行了严格处理，不返回有用的错误信息时，攻击者可能会采用盲注的方式。盲注是通过间接的方式获取数据库信息。
  • 例如，在一个根据用户 ID 显示用户信息的 POST 请求场景中，假设服务器端的 SQL 语句是：

SELECT * FROM users WHERE user_id = [从POST请求获取的用户ID];

攻击者可以注入类似这样的语句：

AND (SELECT ASCII(SUBSTRING(password, 1, 1)) FROM users WHERE username = 'admin') > [某个字符的ASCII值]

攻击者通过逐步改变[某个字符的ASCII值]并观察页面行为（如页面加载时间是否变化、是否显示特定元素等），可以逐个字符地猜出数据库中存储的敏感信息（如管理员密码），即使没有直接看到查询结果。

• 4.POST 请求 SQL 注入的危害

  • 隐私泄露：攻击者可以获取用户账户信息、个人隐私数据等存储在数据库中的敏感信息。例如，通过注入获取用户的银行账户信息、联系方式等。
  • 数据篡改和破坏：能够修改或删除数据库中的数据，如修改用户订单金额、删除重要的业务记录等。这会对业务的正常运行产生严重的影响，可能导致财务损失或业务中断。
  • 系统安全受损：如果攻击者获取了足够的权限，可能会进一步利用系统漏洞，如上传恶意文件、执行远程命令等，从而完全控制服务器。

• 5.防范 POST 请求 SQL 注入的方法

  • 输入验证和过滤：
    • 对 POST 请求中的所有数据进行严格的验证，确保其符合预期的格式和内容。例如，对于用户名和密码，验证长度、字符范围等。
    • 使用正则表达式来过滤可能导致 SQL 注入的特殊字符。例如，去除单引号、双引号、分号等可能改变 SQL 语句结构的字符。不过，要注意过度过滤可能会影响正常的用户输入。
  • 参数化查询（预处理语句）：
    • 采用参数化查询技术，将数据与 SQL 命令分开处理。例如，在 Java 中使用 JDBC（Java Database Connectivity）的参数化查询：

• String sql = "SELECT * FROM users WHERE username =? AND password =?";
  PreparedStatement pstmt = connection.prepareStatement(sql);
  pstmt.setString(1, username); // 假设username和password是从POST请求获取并经过验证的参数
  pstmt.setString(2, password);
  ResultSet rs = pstmt.executeQuery();
  

• 这样，即使攻击者试图在参数中注入 SQL 语句，也不会被执行，因为参数被视为纯粹的数据，而不是 SQL 语句的一部分。
• 安全编码实践和培训：
• 开发人员应该遵循安全编码原则，了解 SQL 注入的原理和防范方法。定期进行安全培训，提高开发人员对安全漏洞的敏感度，有助于减少因代码编写不当而导致的 SQL 注入风险。

（三）cookie（按照位置来划分）

1.取数据

用  $_COOKIE

2.“http header”

      在 Pikachu 靶场的 “HTTP Header” 注入场景中利用 Cookie 进行请求，原因：Cookie 是请求头的重要组成部分，而且这种攻击方式能够利用服务器对 Cookie 处理过程中的漏洞来实现攻击目的。

2.1登录

2.1.1登陆成功

第一步点开“http header”

拦截——发送——渲染后会出现登录成功的页面

2.1.2登录失败

如果回到页面点击退出

然后再把网址换成登录成功后的网址

这样就会导致登录失败

原因是：

退出登录后，浏览器就把cookie清理掉了，如果在此基础上想访问登陆成功的页面是访问不了的。

2.2理解 HTTP Header 注入

 HTTP Header 注入是一种攻击方式，攻击者试图通过在 HTTP 请求头中注入恶意数据来篡改服务器的正常逻辑。在 Pikachu 靶场中，这是一种用于模拟和学习安全漏洞的场景。

• 2.3理解 Cookie 和 HTTP 请求的关系

  • Cookie 是在客户端（浏览器）存储的小文本信息，它用于在不同的请求之间保存状态。当浏览器向服务器发送请求时，会自动将与该域名相关的 Cookie 包含在请求头部（HTTP Header）中。
  • 在 HTTP 协议中，请求头包含了很多关于请求的信息，如用户代理（User - Agent）、接受的内容类型（Accept）等，Cookie 也是其中一部分。它可以用于身份验证、会话管理等多种用途。

• 2.4在 Pikachu 靶场 “HTTP Header” 注入场景中的作用

  • 在 Pikachu 靶场的 “HTTP Header” 注入攻击场景中，攻击者可以利用请求头中的信息进行恶意操作。因为服务器会解析这些请求头信息来提供相应的服务。例如，通过修改或注入恶意的 Cookie 值，可以尝试绕过身份验证机制。假设一个应用程序根据 Cookie 中的用户角色信息来判断用户是否有权限访问某些页面。
  • 攻击者可能会尝试修改 Cookie 中的角色字段，从普通用户改为管理员角色，从而获取未授权的访问权限。另外，服务器端代码可能会对请求头中的 Cookie 进行数据库查询等操作。如果代码没有对输入进行足够的安全检查，攻击者就可以通过在 Cookie 中注入 SQL 语句（在 SQL 注入场景下）或其他恶意脚本（如 XSS 场景下，如果 Cookie 值被反射到页面输出）来攻击服务器。

2.5 cookie在http header的作用用

• 2.5.1身份识别与认证

  • 在 HTTP 通信中，Cookie 是一种在客户端（浏览器）和服务器之间传递用户身份信息的重要方式。当用户首次登录一个网站时，服务器会在响应中设置一个或多个 Cookie，这些 Cookie 通常包含能够唯一标识用户身份的信息，如用户 ID、用户名或经过加密的身份令牌等。
  • 例如，在一个基于 Web 的电子邮件系统中，用户登录后，服务器会在 HTTP 响应头中设置一个包含用户唯一标识符的 Cookie。之后，每次用户发送请求（如查看邮件、发送邮件等操作），浏览器会把这个 Cookie 放在 HTTP 请求头中发送给服务器。服务器通过验证这个 Cookie 来确定是哪个用户在进行操作，从而提供个性化的服务并且确保用户访问权限的合法性。

• 2.5.2会话维持

  • Cookie 有助于维持会话状态。在一个会话期间（从用户登录到退出登录或者会话超时），服务器和浏览器通过 Cookie 来跟踪会话相关的各种信息。
  • 以在线购物网站为例，当用户将商品添加到购物车时，服务器可以在 Cookie 中记录购物“车的详细信息，如商品编号、数量、规格等。在整个购物过程中，每次浏览器向服务器发送请求（比如查看购物车、添加新商品到购物车、结算等操作），这个包含购物车信息的 Cookie 就会在 HTTP 请求头中传递给服务器。服务器根据 Cookie 中的信息更新购物车的状态，确保用户在不同页面之间切换时购物车内容的一致性。

• 2.5.3个性化服务与偏好设置

  • 许多网站利用 Cookie 来提供个性化的服务。在 HTTP 请求头中的 Cookie 可以携带用户的偏好信息，网站根据这些信息为用户定制内容。
  • 比如，在新闻网站中，用户可以设置自己感兴趣的新闻类别（如体育、科技、娱乐等）。网站会将这些偏好信息存储在 Cookie 中，并且在每次请求时通过 HTTP 请求头中的 Cookie 获取这些信息。然后，网站根据用户的偏好筛选新闻内容，并将最符合用户兴趣的新闻展示在首页或者推荐列表中，从而提升用户的浏览体验。

• 2.5.6跟踪用户行为与分析

  • 对于网站所有者和运营者来说，Cookie 在 HTTP 请求头中的存在为用户行为跟踪和分析提供了便利。通过在 Cookie 中设置特定的标识符或者记录用户的浏览路径、访问时间等信息，网站可以收集大量的数据。例如，一个电商网站可以通过分析 HTTP 请求头中的 Cookie 来了解用户的购买习惯、浏览的商品类别、在每个页面的停留时间等信息。这些数据可以用于优化网站的布局、商品推荐系统，以及广告投放策略等诸多方面，帮助网站更好地满足用户需求并提高商业效益。

二、按数据位置分类

（一）请求行

（二）请求数据部分

（三）请求头

• 1概念理解

  • SQL 请求头注入是指攻击者通过操纵 HTTP 请求头中的数据来注入恶意 SQL 语句。HTTP 请求头包含了许多关于请求的信息，如用户代理（User - Agent）、引用页（Referer）、Cookie 等。当应用程序在后端处理过程中直接将这些请求头中的数据用于构建 SQL 查询，并且没有对其进行充分的过滤和验证时，就可能发生请求头注入。

• 2‘常见的注入位置

  • 2.1User - Agent 注入

  • 许多应用程序会记录用户代理信息，用于统计分析、用户行为跟踪等目的。例如，一个简单的记录用户访问信息的 SQL 操作可能是这样的：

• INSERT INTO access_logs (user_agent) VALUES ('[从User - Agent头部获取的值]');
  

• 攻击者可以在 User - Agent 头部构造恶意数据，如'); DROP TABLE access_logs; --（假设后端数据库是 MySQL，使用--进行注释），则完整的 SQL 语句变为：

• INSERT INTO access_logs (user_agent) VALUES ('); DROP TABLE access_logs; --');
  

• 这会导致access_logs表被删除，造成数据丢失和应用程序功能异常。

• 2.2Cookie 注入

  • Cookie 用于在客户端和服务器之间传递用户相关信息，如用户 ID、会话 ID 等。如果应用程序在后端直接将 Cookie 值用于 SQL 查询，就存在风险。
  • 例如，一个应用程序根据用户的 Cookie 中的用户 ID 来获取用户信息，SQL 语句可能类似：

• SELECT * FROM users WHERE user_id = [从Cookie中获取的user_id值];
  

• 攻击者可以修改 Cookie 中的user_id值为恶意数据，如10 OR 1 = 1（假设原始合法的 user_id 是一个数字），则 SQL 语句变为：

• SELECT * FROM users WHERE user_id = 10 OR 1 = 1;
  

• 这样攻击者就可能获取到所有用户的信息，而不仅仅是与特定用户 ID 相关的信息。

• 2.3Referer 注入

  • Referer 头通常用于记录用户是从哪个页面链接过来的。在某些情况下，应用程序可能会使用 Referer 头中的信息进行数据库操作。
  • 例如，一个网站统计用户来源页面的功能可能涉及如下 SQL 操作：

• INSERT INTO referer_stats (referer_url) VALUES ('[从Referer头部获取的值]');
  

• 攻击者可以构造恶意的 Referer 值，如http://evil.com/'); DELETE FROM referer_stats; --，这可能会导致referer_stats表中的数据被删除。

• 3攻击的危害

  • 3.1数据泄露

  • 攻击者可能获取敏感的用户信息，如用户账户信息、个人资料等存储在数据库中的数据。

  • 3.2数据篡改

  • 能够修改或删除数据库中的数据，破坏数据的完整性。例如，删除重要的业务记录或者修改订单状态等。

  • 3.3数据库结构破坏

  • 可以通过执行诸如DROP TABLE等命令来破坏数据库的表结构，导致整个应用程序无法正常运行，造成服务中断。

• 4防范措施

  • 4.1输入验证

  • 对从请求头中获取的所有数据进行严格的验证，确保其符合预期的格式和内容。例如，验证 Cookie 中的用户 ID 是否为合法的数字格式。

  • 4.2参数化查询

  • 在将请求头数据用于 SQL 查询时，使用参数化查询（也称为预处理语句）。参数化查询将用户输入视为数据而不是 SQL 命令的一部分，这样即使攻击者试图注入 SQL 语句，也不会被执行。

  • 4.3编码和过滤

  • 对请求头数据进行适当的编码和过滤，去除可能导致 SQL 注入的特殊字符，如单引号、分号、双引号等。不过，编码和过滤应该谨慎使用，因为过度的过滤可能会导致正常功能受到影响。“.