3 SQL注入|数据类型与提交方式|笔记

3.1 SQL注入之数据类型

一、SQL注入渗透与攻防

00:04

1. SQL注入基础入门

1）数字型注入点

01:19

• 定义: 数字型注入点通常出现在类似`http://xxx.

2. SQL注入之MYSQL系统库

08:50

1）数字型注入与字符型注入

08:51

• 数字型注入特点：传递参数为纯数字，SQL语句中直接使用
  id变量，如：id变量，如：id变量，如：
  sql=“SELECT * FROM users WHERE id=$id LIMIT 0,1”
• 字符型注入特点：参数被单引号包裹，SQL语句形如：
  sql="SELECT∗FROMusersWHEREid=′sql=“SELECT * FROM users WHERE id=‘sql="SELECT∗FROMusersWHEREid=′
  id’ LIMIT 0,1”
• 本质区别：字符型注入需要处理单引号闭合问题，而数字型不需要

2）判断SQL注入点的方法

09:08

• 常规测试方法：
  • 使用and 1=1测试条件为真时页面响应
  • 使用and 1=2测试条件为假时页面响应
• 字符型注入特殊现象：由于MySQL的智能过滤机制，在字符型注入中and 1=1/1=2可能不会影响页面显示
• 关键验证步骤：在参数后添加单引号，如id=1’，观察是否报错

3）字符型注入的闭合与过滤机制

13:07

• MySQL智能过滤：对于字符型参数，MySQL会自动忽略单引号内数字后的其他内容
  • 示例：id=‘1 and 1=2’ 实际只会查询id=1的记录
  • 示例：id=‘1dfadfa’ 同样只会查询id=1的记录
• 闭合原理：需要通过添加单引号破坏原有SQL语句结构，如将
  id=′1′变为id=‘1’变为id=′1′变为
  id=‘1’’

4）字符型注入点的确认

15:16

• 确认方法：在参数值后添加单引号，如访问?id=1’
• 报错原理：导致SQL语句变为SELECT * FROM users WHERE id=‘1’’ LIMIT 0,1，出现未闭合的单引号
• 实际应用：
  • 数字型注入：直接使用and 1=1/1=2测试
  • 字符型注入：必须通过单引号测试确认
  • 实际场景中可通过inurl:php?id搜索可能存在注入的页面

3. SQL注入之高权限注入上

16:26

1）数字型注入

16:30

• 基本特征：传递的参数为纯数字类型，如id=28，无需引号包裹
• 判断方法：通过and 1=1或and 1=2等方式测试注入点
• 注意事项：数字型参数也可能被处理为字符型，需要多种方式尝试验证

2）字符型注入

17:23

• 典型场景：传递用户名等字符串参数，如username=SYSOP
• 识别特征：参数值包含字母或特殊字符，通常用引号包裹
• 测试方法：需要尝试单引号或双引号进行闭合测试
• 示例说明：如传递username参数时，系统可能执行类似SELECT * FROM users WHERE username='SYSOP’的查询

3）单引号和双引号的使用

17:57

• 闭合原理：在MySQL中字符串可以用单引号或双引号括起来
• 测试技巧：
  • 单引号闭合：id=1’ and 1=1#
  • 双引号闭合：id=1" and 1=1#
• 特殊情况：当系统使用单引号时，双引号可能被当作普通字符处理
• 源码分析：如$sql=“SELECT * FROM users WHERE id=‘1’’ LIMIT 0,1”;中的引号处理逻辑

4）搜索型注入

19:37

• 核心语法：使用LIKE关键字进行模糊查询，配合通配符%
• 应用场景：电商网站商品搜索、用户模糊查询等
• 注入原理：构造如y%’ or 1=1#的payload，闭合原有查询条件
• 通配符说明：
  • %表示任意多个字符
  • _表示单个字符
• 实际案例：
  • 京东搜索"茅台"：SELECT * FROM products WHERE name LIKE ‘%茅台%’
  • 靶场示例：SELECT * FROM users WHERE username LIKE ‘%y%’ or 1=1#
• 闭合技巧：
  • 使用%'闭合前端的%
  • 使用#注释掉后端多余的%’
• 逻辑运算符：
  • AND：两边条件都必须为真
  • OR：任意一边条件为真即可
• 注意事项：不同数据库的注释符号可能不同（MySQL用#，SQL Server用–）

二、知识小结

3.2 SQL注入之数据提交方式_笔记

一、SQL注入渗透与攻防

00:02

1. 数据提交方式

00:44

1）GET方式注入

03:40

• 基本概念与特点
  • 传递方式: 通过URL网址将数据传送给后台，再带入数据库执行SQL语句
  • 常见场景: 适用于数据不敏感的情况，如公开信息查询
  • 代码特征: 使用id=id=id=_GET[‘id’];方式接收参数
  • 明文传输: 所有参数直接显示在URL中，可见性高
• 技术实现与案例
  • 注入类型: 典型的数字型注入，无单引号或双引号包裹
  • 执行流程:
    • 通过$_GET[‘id’]获取URL参数
    • 直接拼接SQL语句：SELECT * FROM users WHERE id=$id LIMIT 0,1
    • 使用联合查询(union)可直接注入
  • 靶场验证: 访问localhost/sqli-labs-master/Less-2/?id=1可看到返回用户信息
• 优缺点分析
  • 优势:
    • 传输速度快: 数据从前端到后端传递效率高
    • 简单直观: 参数直接显示在URL中，便于调试
  • 劣势:
    • 安全性低: 参数明文传输，易被截获和篡改
    • 长度限制: 仅支持约2KB的数据传输
    • 敏感暴露: 重要参数可能通过浏览器历史记录、服务器日志等泄露
• 防御建议
  • 参数过滤: 对$_GET接收的所有参数进行严格过滤
  • 长度限制: 控制GET请求的URL最大长度
  • 敏感操作: 重要操作避免使用GET方式提交
  • 加密处理: 必要时对URL参数进行加密编码
• 例题：GET方式注入实战
  • 题目解析
    • 环境搭建: 使用PHPStudy搭建本地测试环境
    • 注入点识别: 观察URL中id=1参数的变化
    • 攻击验证: 尝试修改id值为1’ or 1=1–等注入语句
    • 结果分析: 成功返回数据库信息说明存在注入漏洞
    • 防御方案: 建议使用预处理语句或参数化查询

2）POST方式注入

08:26

• 数据提交方式对比08:54
  • GET方式：
    • 传递方式：通过URL进行数据传递
    • 适用场景：数据不敏感、安全性要求不高
    • 长度限制：最大2KB
    • 速度：非常快
    • 可见性：数据在URL中可见
    • 代码示例：id=id =id=_GET[‘id’];
  • POST方式：
    • 传递方式：直接传递给服务器
    • 适用场景：表单提交（特别是登录框注入）
    • 长度限制：不限
    • 速度：相对较慢
    • 可见性：数据不在URL中显示
    • 代码示例：uname=uname =uname=_POST[‘uname’];
• 核心区别
  • 根本区分点：
    • URL中有数据 → 一定是GET方式
    • URL中无数据 → 可能是POST方式
  • 注意事项：
    • 不能仅依赖抓包工具显示的请求方法
    • POST提交的数据在请求体中，GET在URL中
    • 表单的method属性可以手动修改，但实际传输方式取决于数据位置
• 靶场实例分析
  • 靶场第11关特点：
    • 标准登录页面
    • 使用form表单提交
    • method属性明确设置为post
    • 源代码中通过$_POST接收参数
  • 数据流分析：
    • 用户名和密码通过请求体传输
    • 后端SQL语句：SELECT username, password FROM users WHERE username=‘uname′andpassword=′uname' and password='uname′andpassword=′passwd’
• 抓包工具验证
  • GET请求特征：
    • 请求行包含查询参数（如?id=1）
    • 数据在URL中可见
  • POST请求特征：
    • 请求行仅包含路径
    • 数据在请求体中（如uname=zhangsan&passwd=12345）
    • 需要借助抓包工具查看完整请求
• 安全注意事项
  • 安全性权衡：
    • GET：速度快但安全性低
    • POST：安全性高但速度慢
  • 设计原则：
    • 敏感数据必须使用POST
    • 非敏感数据可考虑GET提升性能
    • 永远不要相信客户端提交的数据，必须进行过滤和验证

3）REQUEST方式注入

18:32

• 超全局变量与提交方式
  • 超全局变量概念：PHP中的预定义变量如REQUEST、_REQUEST、R​EQUEST、_POST、$_GET等，在整个脚本作用域都可使用
  • REQUEST功能​∗∗​：可获取GET/POST/COOKIE传参（注意：新版PHP已无法通过_REQUEST功能​​：可获取GET/POST/COOKIE传参（注意：新版PHP已无法通过R​EQUEST功能​∗∗​：可获取GET/POST/COOKIE传参（注意：新版PHP已无法通过_REQUEST获取COOKIE）
  • Header注入原理：利用后端未处理的客户端信息（如User-Agent、Cookie等header字段）与数据库交互时产生的注入漏洞
• 数据提交方式对比
  • GET方式特点：
    • 通过URL传递数据
    • 适用场景：非敏感数据
    • 安全性低，长度限制2KB
    • 传输速度快
    • 典型代码：id=id =id=_GET[‘ID’]
  • POST方式特点：
    • 直接传递给服务器
    • 适用场景：表单提交/登录框注入
    • 安全性较高，长度不限
    • 传输速度较慢
    • 典型代码：name=name =name=_POST[‘name’]
    • 测试方法：需借助BurpSuite等抓包工具修改重放
• Cookie提交方式
  • 特殊性质：
    • 属于头部提交方式，但严格来说不算数据提交方式
    • 仍可与后端服务器进行数据交互
    • 典型接收代码：c=c =c=_COOKIE[‘c’]
  • 实操演示：
    • 通过修改请求头中的Cookie字段（如Cookie: c=222）
    • 后端通过$_COOKIE超全局变量获取值
    • 实际网站应用：常用于用户登录状态保持
• 例题：REQUEST方式注入19:34
  • 代码分析：
    • 演示了通过GET、_GET、G​ET、_POST、$_COOKIE接收参数的PHP代码结构
    • 重点展示了Cookie参数的接收和输出：echo$_COOKIE[‘c’]
  • BurpSuite实操：
    • 在请求头中添加Cookie字段进行测试
    • 注意PHP中$_COOKIE必须大写
    • 常见问题：400错误可能由参数名大小写错误导致
  • 实战观察：
    • 通过浏览器开发者工具查看实际网站的Cookie
    • 强调Cookie注入点的寻找方法：检查是否与数据库存在交互

4）HTTP头注入

25:27

• 概念与提交方式

  • 定义：利用后端验证客户端信息（如cookie验证）或通过header获取客户端信息时产生的注入漏洞
  • 常见场景：包括cookie验证、User-Agent等header信息的处理
  • PHP超全局变量：
    • $_REQUEST：可获取GET/POST/COOKIE传参（新版本已无法获取COOKIE）
    • $_GET：专门获取GET传参
    • $_POST：专门获取POST传参
    • $_COOKIE：获取COOKIE传参
    • $_SERVER：包含头部信息、路径等服务器信息

• 数据提交方式对比

  • GET方式：
    • 特点：通过URL传输数据，长度限制约2KB，速度快但安全性低
    • 写法示例：id=id=id=_GET[‘id’]
    • 适用场景：常用于显式参数传递，可直接在地址栏看到参数
  • POST方式：
    • 特点：直接传递给服务器，长度不限但速度较慢，安全性较高
    • 测试方法：需使用BurpSuite等抓包工具修改重放
    • 写法示例：name=name=name=_POST[‘name’]
    • 适用场景：表单提交、登录框等敏感信息传输
  • COOKIE方式：
    • 特点：存储在客户端的小型文本文件
    • 写法示例：c=c=c=_COOKIE[‘c’]
    • 测试要点：需注意不同浏览器对cookie的处理差异

• REQUEST接收方式

  • 综合特性：
    • 可同时接收GET/POST/COOKIE多种提交方式
    • 开发时无需预先确定前端提交方式
    • 实际渗透测试中遇到REQUEST接收时，无需区分原始提交方式
  • 代码示例：
    id=id =id=
    _GET[‘id’]; // 仅接收GET
    id=id =id=
    _POST[‘id’]; // 仅接收POST
    // REQUEST方式
    id=id =id=
    _REQUEST[‘id’]; // 同时接收GET/POST

• 实战意义：当发现后端使用REQUEST接收参数时，可直接尝试各种注入方式，无需考虑原始参数传递方式

• 手工注入演示

  • 测试环境搭建：
    • 使用sqli-labs的Less-2（GET注入）和Less-11（POST注入）关卡
    • 修改源代码将接收方式统一改为$_REQUEST
  • 测试过程：
    • GET方式测试：通过URL直接传参?id=1’，观察报错
    • POST方式测试：使用BurpSuite拦截修改表单数据
    • 验证两种方式在REQUEST接收下的兼容性
  • 关键发现：
    • 无论原始提交方式如何，REQUEST均可正常接收参数
    • 在实际渗透中大大简化了测试流程，无需预先判断提交方式

二、结束

29:21

• 靶场练习安排：课程结束后会提供对应靶场练习，包括GET传输第11关和头部传输20万关卡（第一关和第二关不讲）
• 头部注入原理：HTTP头部包含四个部分，只要能与后台进行数据交互的部分都可能存在SQL注入点
• 注入方式特点：头部注入虽然比较少见，但确实是可行的注入途径之一

三、获取当前主机名

32:07

• service函数功能：PHP全局函数，可获取浏览器语言、用户IP地址、主机名、URL等信息
• 典型应用场景：
  • 网站适配不同终端（PC/移动端）
  • 获取用户环境信息（如站长之家的IP查询功能）
• 实现原理：通过解析HTTP请求头部信息获取相关参数

四、站长之家域名查询

33:03

• 查询内容：可显示访问者的IP地址、地理位置、操作系统、分辨率、浏览器语言等信息
• 技术实现：类似PHP的service函数工作原理，通过解析HTTP头部信息实现
• 实际应用：常用于网站统计分析、多终端适配、地域限制等功能实现

五、常用的数据提交方式

35:50

• 主要提交方式：
  • GET/POST：最常用的两种数据提交方式
  • Cookie：存储在客户端的会话信息
  • Request：包含请求的各种参数
  • Service：获取客户端环境信息
• 安全注意：所有能与后台交互的数据通道都可能存在注入漏洞
• 后续内容：将在SQL注入靶场中具体演示不同提交方式的注入方法

六、知识小结

3.3 SQL注入之靶场案例练习_笔记

一、SQL注入渗透与攻防

00:02

1. 课程说明

00:57

• 课程内容：本课程主要讲解SQL注入的基础知识，包括数据类型、提交方式以及靶场案例练习。
• 学习目标：通过实践掌握SQL注入的手工注入技巧，重点理解不同提交方式和数据类型的区别与应用。

2. SQL注入基础知识

1）提交方式

• 常见类型：包括GET提交、POST提交、Cookie数据交互以及头部数据提交。
• 实践工具：使用Burp Suite抓包修改参数是常见的测试手段。

2）数据类型

• 字符型注入：如Less-11关，基于POST提交方式的字符型注入。
• 数字型注入：如Less-1到Less-6关，主要与数字类型相关，建议自行练习。
• Cookie型注入：如Less-20关，基于Cookie的注入题型。

3. 靶场案例练习

01:15

1）Less-11关

• 题目特点：基于POST提交方式的字符型注入。
• 解题思路：通过Burp Suite抓包修改参数，尝试构造注入语句。

2）Less-20关

• 题目特点：基于Cookie的注入题型，涉及头部POST注入。
• 解题技巧：需要关注Cookie字段的构造和错误回显。

4. 实践建议

• 练习顺序：建议从数字型注入（Less-1到Less-6）开始，逐步过渡到字符型和Cookie型注入。
• 工具使用：熟练掌握Burp Suite等工具对提高注入效率至关重要。

二、SQL注入靶场案例练习

1. 第11关POST提交练习

1）目标数据类型分析

02:26

• 数据类型判断：登录页面的账号密码通常是字符串类型，SQL语句中会使用单引号包裹参数
• 源码分析：通过查看源码确认SQL语句为SELECT username, password FROM users WHERE username=‘uname′andpassword=′uname' and password='uname′andpassword=′passwd’
• 参数获取方式：使用POST或_POST或P​OST或_REQUEST获取参数，$_REQUEST可同时接收GET/POST/COOKIE数据

2）遇到这种提交的做法

03:37

• 修改位置：POST数据需在请求体(Request Body)中修改，无法通过URL直接修改
• 工具选择：推荐使用Burp Suite等抓包工具进行参数修改和注入测试
• 注入点判断：在username或password字段均可注入，因为两个参数都会传递到SQL语句执行

3）社会语句写法

05:11

• 基础语句：SELECT username, password FROM users WHERE username=‘zhangsan’ and password=‘12345’ LIMIT 0,1
• 注入构造：
  • 闭合单引号：username=‘zhangsan’ → username=‘zhangsan’ and 1=1–
  • 注释后续：使用-- 或#注释掉原语句的剩余部分
• 测试方法：通过and 1=1和and 1=2测试页面响应差异

4）抓包分析

05:31

• 请求结构：
  • 请求方式：POST
  • 参数格式：uname=zhangsan&passwd=12345&submit=Submit
  • Content-Type：application/x-www-form-urlencoded
• 修改要点：
  • 保持参数格式完整
  • 注意特殊字符的URL编码
  • 修改后需Forward转发请求

5）判断注入点

06:18

• 测试步骤：
  • 输入admin’ and 1=1-- 测试真条件
  • 输入admin’ and 1=2-- 测试假条件
  • 观察页面响应差异
• 结果分析：若真/假条件导致不同响应，则存在SQL注入漏洞
• 盲注情况：当页面无显错时，需采用盲注技术判断

6）使用盲注

10:49

• 技术选择：使用联合查询union select进行盲注
• 字段判断：
  • 初始猜测：union select 1,2–
  • 确认字段：通过回显位置确定可用字段
• 信息获取：
  • 数据库名：union select 1,database()–
  • 后续操作：获取表名→列名→数据
• 技巧：使前段查询失败（如username=-1’）确保联合查询结果回显

7）内容总结

14:03

• 关键步骤：
  • 使用抓包工具拦截POST请求
  • 修改请求体中的参数值
  • 注意参数数据类型和引号闭合
  • 通过真/假条件测试确认注入点
• 注意事项：
  • POST注入无法通过URL直接操作
  • 实战中通常无法查看源码，需通过响应判断
  • 字符串类型参数必须正确处理引号
• 延伸技巧：相同方法可用于Cookie注入等非GET型注入场景

2. 第20关Cookie注射练习

14:37

1）目标代码分析

15:27

• 防御机制：
  • 使用check_input()函数处理用户输入
  • 开启魔术引号(get_magic_quotes_gpc())
  • 对非数字值使用mysql_real_escape_string()转义
  • 对数字值使用intval()强制转换
• 函数处理流程：
  • 截取前20个字符(substr($value, 0, 20))
  • 魔术引号处理(stripslashes())
  • 非数字值添加引号并转义
  • 数字值转换为整数
• 注入难点：
  • POST参数经过严格过滤
  • 单引号会被转义(')，无法闭合SQL语句
  • 数字输入会被强制转换类型
• 漏洞点：
  • 从Cookie获取uname时未经过滤
  • 直接拼接进SQL语句：SELECT * FROM users WHERE username=‘$cookee’
  • Cookie值在登录成功后通过setcookie()设置

2）直接通过Cookie注入

19:56

• 绕过方法：
  • 使用Burp Suite拦截请求
  • 修改Cookie头中的uname参数
  • 构造Payload：-admin’ union select 1,2,database()–+
• 技术要点：
  • 前导负号使原查询报错
  • 联合查询获取数据库信息
  • –+注释掉后续语句
• 执行结果：
  • 成功显示当前数据库名
  • 可继续获取表名、字段名等
  • 完全绕过前端过滤机制
• 防御建议：
  • 对Cookie值进行同等严格过滤
  • 使用预处理语句替代拼接SQL
  • 最小化数据库用户权限

三、知识小结

一、SQL注入渗透与攻防

00:02

1. 课程说明

00:57

• 课程内容：本课程主要讲解SQL注入的基础知识，包括数据类型、提交方式以及靶场案例练习。
• 学习目标：通过实践掌握SQL注入的手工注入技巧，重点理解不同提交方式和数据类型的区别与应用。

2. SQL注入基础知识

1）提交方式

• 常见类型：包括GET提交、POST提交、Cookie数据交互以及头部数据提交。
• 实践工具：使用Burp Suite抓包修改参数是常见的测试手段。

2）数据类型

• 字符型注入：如Less-11关，基于POST提交方式的字符型注入。
• 数字型注入：如Less-1到Less-6关，主要与数字类型相关，建议自行练习。
• Cookie型注入：如Less-20关，基于Cookie的注入题型。

3. 靶场案例练习

01:15

1）Less-11关

• 题目特点：基于POST提交方式的字符型注入。
• 解题思路：通过Burp Suite抓包修改参数，尝试构造注入语句。

2）Less-20关

• 题目特点：基于Cookie的注入题型，涉及头部POST注入。
• 解题技巧：需要关注Cookie字段的构造和错误回显。

4. 实践建议

• 练习顺序：建议从数字型注入（Less-1到Less-6）开始，逐步过渡到字符型和Cookie型注入。
• 工具使用：熟练掌握Burp Suite等工具对提高注入效率至关重要。

二、SQL注入靶场案例练习

1. 第11关POST提交练习

1）目标数据类型分析

02:26

• 数据类型判断：登录页面的账号密码通常是字符串类型，SQL语句中会使用单引号包裹参数
• 源码分析：通过查看源码确认SQL语句为SELECT username, password FROM users WHERE username=‘uname′andpassword=′uname' and password='uname′andpassword=′passwd’
• 参数获取方式：使用POST或_POST或P​OST或_REQUEST获取参数，$_REQUEST可同时接收GET/POST/COOKIE数据

2）遇到这种提交的做法

03:37

• 修改位置：POST数据需在请求体(Request Body)中修改，无法通过URL直接修改
• 工具选择：推荐使用Burp Suite等抓包工具进行参数修改和注入测试
• 注入点判断：在username或password字段均可注入，因为两个参数都会传递到SQL语句执行

3）社会语句写法

05:11

• 基础语句：SELECT username, password FROM users WHERE username=‘zhangsan’ and password=‘12345’ LIMIT 0,1
• 注入构造：
  • 闭合单引号：username=‘zhangsan’ → username=‘zhangsan’ and 1=1–
  • 注释后续：使用-- 或#注释掉原语句的剩余部分
• 测试方法：通过and 1=1和and 1=2测试页面响应差异

4）抓包分析

05:31

• 请求结构：
  • 请求方式：POST
  • 参数格式：uname=zhangsan&passwd=12345&submit=Submit
  • Content-Type：application/x-www-form-urlencoded
• 修改要点：
  • 保持参数格式完整
  • 注意特殊字符的URL编码
  • 修改后需Forward转发请求

5）判断注入点

06:18

• 测试步骤：
  • 输入admin’ and 1=1-- 测试真条件
  • 输入admin’ and 1=2-- 测试假条件
  • 观察页面响应差异
• 结果分析：若真/假条件导致不同响应，则存在SQL注入漏洞
• 盲注情况：当页面无显错时，需采用盲注技术判断

6）使用盲注

10:49

• 技术选择：使用联合查询union select进行盲注
• 字段判断：
  • 初始猜测：union select 1,2–
  • 确认字段：通过回显位置确定可用字段
• 信息获取：
  • 数据库名：union select 1,database()–
  • 后续操作：获取表名→列名→数据
• 技巧：使前段查询失败（如username=-1’）确保联合查询结果回显

7）内容总结

14:03

• 关键步骤：
  • 使用抓包工具拦截POST请求
  • 修改请求体中的参数值
  • 注意参数数据类型和引号闭合
  • 通过真/假条件测试确认注入点
• 注意事项：
  • POST注入无法通过URL直接操作
  • 实战中通常无法查看源码，需通过响应判断
  • 字符串类型参数必须正确处理引号
• 延伸技巧：相同方法可用于Cookie注入等非GET型注入场景

2. 第20关Cookie注射练习

14:37

1）目标代码分析

15:27

• 防御机制：
  • 使用check_input()函数处理用户输入
  • 开启魔术引号(get_magic_quotes_gpc())
  • 对非数字值使用mysql_real_escape_string()转义
  • 对数字值使用intval()强制转换
• 函数处理流程：
  • 截取前20个字符(substr($value, 0, 20))
  • 魔术引号处理(stripslashes())
  • 非数字值添加引号并转义
  • 数字值转换为整数
• 注入难点：
  • POST参数经过严格过滤
  • 单引号会被转义(')，无法闭合SQL语句
  • 数字输入会被强制转换类型
• 漏洞点：
  • 从Cookie获取uname时未经过滤
  • 直接拼接进SQL语句：SELECT * FROM users WHERE username=‘$cookee’
  • Cookie值在登录成功后通过setcookie()设置

2）直接通过Cookie注入

19:56

• 绕过方法：
  • 使用Burp Suite拦截请求
  • 修改Cookie头中的uname参数
  • 构造Payload：-admin’ union select 1,2,database()–+
• 技术要点：
  • 前导负号使原查询报错
  • 联合查询获取数据库信息
  • –+注释掉后续语句
• 执行结果：
  • 成功显示当前数据库名
  • 可继续获取表名、字段名等
  • 完全绕过前端过滤机制
• 防御建议：
  • 对Cookie值进行同等严格过滤
  • 使用预处理语句替代拼接SQL
  • 最小化数据库用户权限

三、知识小结