SQL 注入载荷测试沙盒 - 安全执行并展示语法

原理：当应用程序将用户输入直接拼接到SQL语句中时，攻击者可以注入额外的SQL子句（如OR、UNION、DROP等），改变原始查询的逻辑。

示例：原始查询 SELECT * FROM users WHERE name = '{input}'，如果input为 ' OR '1'='1，则变成 SELECT * FROM users WHERE name = '' OR '1'='1'，返回所有用户。

• 联合查询注入(UNION)：利用UNION SELECT合并查询结果，获取其他表数据。
• 布尔盲注：通过页面响应的差异（真/假）逐字符推断数据。
• 时间盲注：使用SLEEP()等函数，通过响应时间差异推断数据。
• 堆叠查询：使用分号;执行多条SQL语句（依赖数据库支持）。
• 错误注入：利用数据库错误消息泄露信息。

核心防御措施：

1. 参数化查询：使用PreparedStatement（Java）、参数化查询（Python/Go）等。
2. 输入验证：白名单验证、类型检查、长度限制。
3. 转义处理：对特殊字符进行转义（作为辅助手段）。
4. 最小权限：数据库账户只授予必要的权限。
5. WAF：部署Web应用防火墙作为额外防护层。

工作流程：

1. 发送SQL模板（含占位符?）到数据库 → 2. 数据库编译SQL结构 → 3. 绑定用户输入作为参数值 → 4. 执行

关键点：用户输入在编译之后才绑定，因此无法改变SQL的语法结构。即使输入包含 ' OR '1'='1，它只会被当作字符串字面值处理。

著名案例包括：

• TalkTalk (2015)：SQL注入导致15万用户数据泄露，被罚款40万英镑。
• Yahoo Voices (2012)：45万用户凭证通过SQL注入被盗。
• Heartland Payment Systems (2008)：大规模信用卡数据泄露，损失超1.4亿美元。
• GhostShell攻击 (2012)：利用SQL注入从多个大学和政府机构泄露数据。

ORM的局限性：

• 使用原生SQL（raw queries）时仍需参数化。
• 动态构建查询条件时可能引入注入点。
• 某些ORM方法（如order_by的动态参数）可能不安全。
• 最佳实践：始终使用ORM的绑定参数功能，避免字符串拼接。

攻击流程：

1. 攻击者提交含注入载荷的数据（如注册用户名） → 2. 数据被安全存储 → 3. 后续功能读取该数据并拼接到SQL中 → 4. 注入被触发

防御：不仅在输入时验证，在所有使用数据的地方（包括从数据库读取的数据）都应使用参数化查询。