API网关中，课程预约API存在SQL注入风险，请分析漏洞原因，并给出修复方案。
答案
1) 【一句话结论】课程预约API因用户输入未做有效验证/转义，直接嵌入SQL语句，导致恶意构造的SQL被执行（如绕过ID验证、获取敏感数据），属于SQL注入漏洞。
2) 【原理/概念讲解】SQL注入的核心是用户输入被错误地嵌入到SQL语句中，导致数据库执行非预期的操作。比如，当API接收用户输入（如课程ID）后，直接拼接成SQL语句（如SELECT * FROM courses WHERE id = ${courseId}），若用户输入为1' or '1'='1' --，则SQL变为SELECT * FROM courses WHERE id = '1' or '1'='1' --，数据库会执行该语句（因为'1' or '1'='1'为真），从而绕过验证。类比：就像把用户的话直接放进法官的判决书里，导致判决结果被篡改。
3) 【对比与适用场景】
| 对比项 | 参数化查询（Prepared Statements） | 字符串拼接（拼接SQL） |
|---|---|---|
| 定义 | 将SQL语句和参数分开处理，参数用占位符（如?），数据库引擎解析后绑定参数 | 将用户输入直接嵌入SQL字符串，通过字符串拼接生成完整SQL |
| 特性 | 防注入，参数被当作数据而非代码 | 容易注入，用户输入会被解释为SQL代码 |
| 使用场景 | 通用，处理用户输入的SQL操作 | 仅用于已知安全输入（如静态SQL，无用户输入） |
| 注意点 | 需正确绑定参数，避免类型不匹配；部分数据库可能支持部分转义，但不如参数化安全 | 需严格过滤所有特殊字符（如单引号、分号），但仍有风险 |
4) 【示例】
请求示例（POST请求，body为JSON）：
- 正常请求：
{"courseId": "101"} - 恶意请求：
{"courseId": "1' or '1'='1' --"}
对应的SQL语句： - 正常：
SELECT * FROM course WHERE id = 101 - 恶意：
SELECT * FROM course WHERE id = '1' or '1'='1' --（执行结果为所有课程，绕过ID验证）
5) 【面试口播版答案】（约80秒）
“面试官您好，关于课程预约API的SQL注入风险，核心原因是用户输入（如课程ID）未经过有效验证或转义，直接嵌入SQL语句，导致恶意构造的SQL被执行。比如，当用户输入1' or '1'='1' --时，原本的SELECT * FROM courses WHERE id = ${courseId}会被解析为SELECT * FROM courses WHERE id = '1' or '1'='1' --，数据库会执行该非法查询，绕过课程ID的验证逻辑。修复方案主要是采用参数化查询（Prepared Statements），将用户输入作为参数绑定，而非拼接字符串。具体来说，用占位符（如?）代替用户输入部分，数据库引擎会正确处理参数，避免SQL语句被篡改。比如，将SQL改为SELECT * FROM courses WHERE id = ?，然后传入参数courseId，这样无论用户输入什么，都会被当作数据而非代码，从而防止注入。总结来说，问题在于输入处理方式不当，修复核心是参数化查询，确保用户输入不被解释为SQL代码。”
6) 【追问清单】
- 问1：如何检测SQL注入？
回答要点：可通过模糊测试工具（如SQLMap）模拟注入，或编写测试用例（如输入特殊字符、构造条件语句），观察数据库响应（如错误信息、返回数据变化）。 - 问2：除了参数化查询，还有其他防护措施吗？
回答要点：输入验证（过滤特殊字符，如单引号、分号）、输出编码（防止XSS，同时辅助防护注入）、最小权限原则（数据库用户仅执行必要操作）、日志监控（记录异常SQL执行）。 - 问3：如果API网关有中间层，如何处理？
回答要点：网关可做初步验证（如白名单校验），但核心仍需后端应用处理，因为网关无法完全解析SQL逻辑；需后端应用实现参数化查询，确保数据传输到数据库前已正确处理。 - 问4：修复后如何验证？
回答要点：编写单元测试和集成测试用例，覆盖正常输入和恶意输入，检查数据库执行结果是否正确（如正常输入返回指定课程，恶意输入返回错误或空结果），同时监控数据库日志，确保无异常SQL执行。
7) 【常见坑/雷区】
- 坑1：仅过滤特殊字符（如单引号）不够，因为攻击者可能用其他方式绕过（如使用编码、注释符）。
雷区：认为“过滤所有单引号”就能解决，实际上参数化查询更可靠。 - 坑2：参数化查询未正确绑定参数，导致类型不匹配（如字符串参数传入数字类型）。
雷区：需确保参数类型与数据库字段类型一致，否则可能引发错误或绕过。 - 坑3：缓存导致注入漏洞被绕过。
雷区：如果API结果被缓存，攻击者可能通过缓存绕过，需配置缓存不存储敏感数据或设置过期策略。 - 坑4：忽略其他注入场景（如存储过程、动态SQL）。
雷区：课程预约API可能涉及存储过程调用，需检查存储过程是否安全，是否使用参数化。 - 坑5：只关注前端输入验证，忽略后端处理。
雷区：前端验证是辅助，后端必须做最终验证，因为前端可能被绕过（如直接修改请求参数）。