💉 A03 注入攻击

📌 一句话概括

注入攻击是指攻击者将恶意数据作为代码/命令发送到解释器执行——SQL 注入是最经典的形态，但 NoSQL、OS 命令、LDAP、XML 等同样存在注入风险，核心问题是"数据"被当成了"代码"。

💡 核心原理

① 注入攻击三要素

• 不可信数据源：用户输入、HTTP Header、文件上传、第三方 API
• 动态拼接：未使用参数化查询/预编译，直接用字符串拼接构建命令
• 解释器执行：拼接后的字符串被数据库/Shell/解析器当作代码执行

② 银行系统常见注入面

• 查询类接口：交易流水查询、客户信息检索（参数易注入）
• 报表功能：动态拼接 SQL 生成报表（经典重灾区）
• 批处理脚本：Shell 调用中参数未校验

🔍 测试实战

1. SQL 注入检测

操作：在输入框/参数中注入 ' OR 1=1 --、" OR "1"="1、; DROP TABLE users -- 等 payload

工具：sqlmap（自动化检测）

指标：注入检测率、payload 绕过率、注入点数量

2. NoSQL 注入（MongoDB）

操作：JSON 参数中注入 {"$gt": ""} 绕过查询限制，或 {"$ne": ""} 绕过认证

工具：Burp Suite + 自定义 payload

指标：NoSQL 注入检出率

3. 二阶注入测试

操作：先提交含 payload 的数据（如用户名设为 test' OR '1'='1），在列表页/详情页查看是否触发

评估：二阶注入场景常被忽略，但银行系统中"先存储后展示"的流程很常见

⚠️ 常见坑点

1. ORM 不是免死金牌：MyBatis/Hibernate 中如果使用 ${} 拼接（而不是 #{} 参数化），依然有注入风险
2. 存储过程也未必安全：存储过程内部若动态拼接 SQL，同样存在注入点
3. 只测 SQL 不测其他注入：LDAP 注入、XPath 注入、模板注入（SSTI）在银行系统中同样常见

📖 延伸阅读

• sqlmap - 自动化 SQL 注入工具
• PortSwigger SQL 注入教程
• OWASP SQL 注入防护速查表