SQL注入攻击分析报告

该报告针对承载核心业务与敏感数据的系统开展审计，通过 Wireshark、Notepad++ 等工具及 ASCII 转换、AI 辅助分析，发现 message.php 的 id 参数存在 SQL 布尔盲注漏洞，还原出 isg.flags 表的敏感数据 ISG {AKimc_SQk_ImlEcSi/M_CeSEcSEc}}，指出权限管控不当等高危风险，并给出漏洞修复、权限优化、日志监控搭建等分级整改建议。

一、简介

1.目的

为何开展此次审计？

本次审计旨在通过技术手段识别目标系统的安全脆弱点、验证现有安全防护措施的有效性，并确保系统符合ISO 27001 信息安全管理体系标准，最终降低数据泄露、恶意攻击等安全风险。

2.意义

被审计系统的业务重要性

被审计系统承载核心业务应用（message.php）及敏感数据存储（isg 数据库），其中isg.flags 表属于核心敏感数据载体，直接关联业务机密性与数据完整性。系统安全直接影响业务连续性，若存在漏洞可能导致敏感数据泄露、应用服务中断，因此本次审计对保障业务安全至关重要。

二、审计范围和目标

1.范围

审计的系统、网络、应用等。

|------|-------------------------------------------------|
| 系统层面 | 客户端（IP：10.0.0.101）、Web 服务器（IP：10.0.0.201，端口 80） |
| 网络层面 | HTTP 协议流量（重点：message.php 相关请求） |
| 应用层面 | Web 应用程序（message.php，含 id 参数交互逻辑） |
| 数据层面 | isg 数据库（重点：isg.flags 表及数据访问权限） |

2.目的

识别脆弱点、验证防护有效性、确保符合ISO 27001标准等

识别系统存在的安全脆弱点（如注入、权限越权等）；
验证现有防护措施（如访问控制、日志记录）的有效性；
确保系统符合 ISO 27001 标准对敏感数据保护、漏洞管理的要求；
提取潜在恶意行为证据（如 SQL 注入尝试）并分析风险影响。

三、审计的方法

常用的系统安全审计方法，如

本次审计采用 "技术工具 + 人工分析 + AI 辅助" 的组合方法，具体如下：

Wireshark 数据包分析：捕获并筛选网络流量，定位含 SQL 盲注特征的 HTTP 请求（如含 "AND ORD (MID ())""isg.flags" 的请求）；
Notepad++ 文本处理：导出数据包解析结果为纯文本，通过正则表达式（HTTP.*id.*isg.flags.*LIMIT.*HTTP）筛选盲注语句，并利用 MIME Tools 插件完成 URL 解码；
ASCII 码字符转换：对盲注获取的 ASCII 码值进行拆解，结合 AI 辅助分析工具，映射为可读字符以还原敏感数据；
权限与合规核查：检查数据库账户权限配置（如 app_user 对 isg.flags 的访问权限）、日志保留周期等，验证是否符合 ISO 27001 要求。

四、审计的流程

审计的流程，如项目准备、数据手机、安全测试、评估等。

项目准备

明确审计范围、目标及工具清单（Wireshark、Notepad++、AI 分析工具、牛族字符转换器），搭建临时分析环境以避免影响生产系统。

打开数据包后，判断流量为布尔类型的SQL盲注将布尔类型为数据筛选出来

筛选出布尔类型 SQL 盲注流量，共捕获帧 746-896 等多组 HTTP 请求（示例：帧 826，592 字节，源 IP 10.0.0.101→目标 IP 10.0.0.201）；

验证流量特征：请求 URL 均含GET /message.php?id=1 AND ORD(MID((SELECT IFNULL(CAST(value AS CHAR)...，符合 SQL 布尔盲注的 "条件判断 + 字符截取" 逻辑。

导出分组解析结果

在 Wireshark 中执行 "文件→导出分组解析结果→为纯文本"，保存所有筛选后的 HTTP 请求详情，包含帧编号、时间戳、源目 IP、请求 URL 等核心信息

将导出的文本通过 notepad++进行编辑把盲注语句筛选出来

将语句标记出来后，把标记的文本复制下来并新建一个文本粘贴上去

打开导出的纯文本文件，使用 "查找→标记" 功能，输入正则表达式HTTP.*id.*isg.flags.*LIMIT.*HTTP，标记出 239 次匹配的盲注语句；

粘贴完后，使用notepad++自带插件解码url，得到sql语句

复制标记文本至新文件，通过 "插件→MIME Tools→URL Decode" 解码 URL 编码字符（如%20解码为空格、%60解码为反引号），得到完整 SQL 盲注语句

盲注结果分析与敏感数据提取

盲注逻辑判断：攻击者通过将 value 字段字符的 ASCII 值与 64 开始的数值比较（如 ">72 为真，>73 为假"），逐步确定每一位字符的精确 ASCII 码；
AI 辅助拆解：按 value 字段第 1-34 位顺序，提取每一位的 ASCII 码并映射为字符（示例：第 1 位 ASCII 73→"I"、第 2 位 83→"S"、第 4 位 123→"{"）；
敏感数据还原：将 34 位 ASCII 码（73 83 71 123 65 75 105 109 99 95 83 81 107 95 73 109 73 69 99 83 105 47 77 95 67 101 83 69 99 83 69 99 125）通过 ASCII 转字符工具，得到最终敏感数据： ISG{AKimc_SQk_ImlEcSi/M_CeSEcSEc}} 。

73 83 71 123 65 75 105 109 99 95 83 81 107 95 73 109 73 69 99 83 105 47 77 95 67 101 83 69 99 83 69 99 125

五、审计结果

系统的整体安全评级和各项风险评估

1.整体安全评级

高危风险：系统存在可被利用的 SQL 布尔盲注漏洞，敏感数据已面临泄露风险，现有防护措施（如权限管控、日志监控）存在明显不足，不符合 ISO 27001 标准要求。

2. 关键风险点评估

|--------------|------------------------------------------------------------------------------|---------------------|
| 风险类型 | 具体描述 | 影响范围 |
| SQL 布尔盲注漏洞 | message.php 的 id 参数未做输入过滤，攻击者可构造含 "AND ORD (MID ())" 的请求，逐字符读取 isg.flags 表数据 | 核心敏感数据（isg.flags）泄露 |
| 数据库权限管控不当 | 应用账户（如 app_user）拥有 isg.flags 表的 SELECT 权限，违反 "最小权限原则" | 越权访问敏感表，扩大数据泄露风险 |
| 日志监控缺失 | Web 服务器（Nginx）未配置完整访问日志（如客户端 IP、请求 URL），数据库未启用审计日志，无法追溯恶意行为 | 无法及时发现、定位攻击行为 |
| 应用层防护空白 | 未部署 WAF（Web 应用防火墙），无法拦截 SQL 注入特征请求 | 攻击者可直接发起恶意请求，攻击成本低 |

3. 敏感数据泄露结果

通过盲注分析，确认 isg.flags 表中的核心敏感数据已被提取，数据内容为：ISG{AKimc_SQk_ImlEcSi/M_CeSEcSEc}}，需立即评估该数据泄露对业务的影响（如是否关联账号、密钥等）。

六、审计建议

提出改进和加强安全措施的建议，如加强密码策略、定期更新补丁等。

（一）紧急整改（1 个月内完成，优先解决高危风险）

修复 SQL 布尔盲注漏洞

1. 代码改造：将message.php等所有涉及 SQL 查询的文件，从 "字符串拼接" 改为 "参数化查询"
2. 临时防护：在 Web 服务器（如 Nginx）配置过滤规则，拦截含ORD(MID(、UNION SELECT、isg.flags的请求

优化数据库账户权限

回收应用账户的敏感表访问权限：执行REVOKE SELECT ON isg.flags FROM 'app_user'@'localhost';，仅保留message等业务表的必要权限；
创建专用审计账户：新增audit_user账户，仅授予数据库审计日志的读取权限，避免应用账户越权访问审计信息。

二）中期优化（3 个月内完成，解决中风险）

完善日志监控体系

1. 日志配置：
Web 服务器：在 Nginx 配置中启用access_log，记录 $remote_addr（客户端 IP）、$ request_uri（请求 URL）、$status（响应状态码），日志保留周期延长至 12 个月；
数据库：启用 MySQL 审计日志（需安装 audit_plugin），记录所有访问isg数据库的 SQL 语句、操作账户、执行时间；
1. 实时监控：部署 SIEM 系统（如 ELK Stack），配置告警规则：当 1 分钟内同一 IP（如 10.0.0.101）访问message.php超过 10 次，或请求含isg.flags时，触发邮件 + 短信告警。

部署应用层防护设备

1. 安装 WAF（Web 应用防火墙），开启 "SQL 注入防护" 模块，更新注入特征库（包含ORD(MID())、IFNULL(CAST())等盲注特征）；
2. 配置 WAF 的 "学习模式"，先记录 3 天内的正常请求流量，再切换为 "防护模式"，避免误拦截合法业务请求。

（三）长期合规（6 个月内完成，满足体系要求）

建立安全开发生命周期（SDL）

1. 在应用程序开发流程中增加 "安全测试" 环节，要求所有涉及用户输入的代码（如 PHP、Java）必须通过 SQL 注入、XSS 等漏洞测试才能上线；
2. 每季度对开发人员开展安全培训，重点讲解参数化查询、输入验证等安全编码方法，结合本次审计发现的message.php漏洞案例进行实操教学。

完成合规体系转版与认证

1. 针对 ISO 27001:2025 转版要求，补充 "敏感数据分类分级" 文档，明确isg.flags表为 "核心敏感数据"，设置单独的访问控制策略；
2. 按 PCI DSS v4.0.1 第 8.3 条要求，对数据库管理员、开发人员等访问 CDE（支付卡数据环境）的账户，启用 "密码 + 硬件令牌" 的多因素认证，禁止使用单一密码登录。