在360安全产品中，如何防止SQL注入攻击？请从输入验证、参数化查询、ORM框架安全配置等方面阐述具体策略。
答案
1) 【一句话结论】
在360安全产品（如引擎）中，防止SQL注入的核心策略是通过输入端严格验证（白名单过滤危险字符）、执行端参数化查询（分离SQL与参数）、结合ORM框架安全配置（自动转义与禁用动态拼接），实现“输入-处理-执行”全链路防护，确保用户输入不会篡改SQL逻辑。
2) 【原理/概念讲解】
SQL注入是指恶意用户通过在输入字段中插入特殊字符（如单引号、分号），构造恶意SQL语句，绕过应用逻辑执行非法操作。具体策略如下：
- 输入验证：对用户输入进行白名单（如用户名仅允许字母数字）或黑名单（过滤单引号、分号）检查，提前拦截恶意字符。类比：就像检查输入的“内容”是否符合规则，不符合则拦截，避免危险字符进入系统。
- 参数化查询：将SQL语句与参数分离，参数作为占位符（如
?或命名参数）传递，数据库引擎按原样执行参数，不会解析参数中的SQL（参数被当作数据而非代码处理）。类比：填空题，用户输入是“空格里的内容”，SQL是“题目”，数据库按题目原样执行，空格内容不影响题目逻辑。 - ORM框架安全配置：ORM工具（如MyBatis、Hibernate）通过自动转义用户输入、禁用动态SQL拼接、提供安全方法（如
setString）传递参数，减少手动拼接SQL的风险。类比：ORM工具自动帮你处理SQL拼接，避免手动拼接时出错。
3) 【对比与适用场景】
| 方法 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 输入验证 | 对用户输入进行字符过滤或格式校验 | 依赖手动规则，可能遗漏复杂注入 | 简单表单、非复杂查询 | 需覆盖所有输入点，否则易被绕过 |
| 参数化查询 | 将SQL语句与参数分离，参数作为占位符传递 | 防止SQL解析，性能较高 | 大多数应用，尤其是动态SQL | 需正确使用占位符（如?或命名参数） |
| ORM框架安全配置 | ORM工具自动处理SQL拼接，提供安全方法 | 减少手动错误，支持复杂查询 | 使用ORM框架的应用 | 需配置安全选项（如自动转义、禁用动态SQL拼接） |
4) 【示例】
假设360引擎中用户登录场景，用户输入用户名“admin' or '1'='1”，密码“123”。正确处理（参数化查询）的伪代码（Python + SQLAlchemy）：
username = request.form.get('username')
password = request.form.get('password')
# 参数化查询
result = session.query(User).filter(User.username == username, User.password == password).first()
if result:
# 登录成功
else:
# 登录失败
恶意输入“admin' or '1'='1”和“123”，参数化查询后，SQL变为SELECT * FROM users WHERE username = 'admin' or '1'='1' AND password = '123'，数据库按原样执行，不会执行“or '1'='1”逻辑（参数被当作字符串处理）。
（若使用MyBatis，配置如下：）
<select id="selectUser" resultType="User">
SELECT * FROM users WHERE username = #{username} AND password = #{password}
</select>
输入验证时，用户名通过正则表达式过滤，仅允许字母数字，过滤单引号后，恶意输入被拦截。
5) 【面试口播版答案】
在360安全产品中，防止SQL注入主要采用三方面策略：一是输入验证，对用户输入进行白名单过滤（如用户名仅允许字母数字），过滤单引号、分号等危险字符；二是参数化查询，将SQL语句与参数分离，用占位符（如?）传递参数，数据库按原样执行，不会解析参数中的SQL（比如登录时用SELECT * FROM users WHERE username = ? AND password = ?，传入用户名和密码，即使输入“admin' or '1'='1”，也不会改变查询逻辑）；三是ORM框架安全配置，比如MyBatis的<set>标签自动转义，Hibernate的setString方法处理参数，减少手动拼接SQL的风险。通过这些措施，从输入到执行全链路防护，有效防止SQL注入攻击。
6) 【追问清单】
- 问：为什么输入验证可能不够？比如用户输入的字符被绕过怎么办？
回答要点：输入验证依赖规则，若规则不完整（如遗漏某些字符组合），或用户输入复杂注入（如多字符拼接），可能被绕过，且手动维护规则成本高，不如参数化查询可靠。 - 问：参数化查询的原理是什么？为什么能防止注入？
回答要点：参数化查询将SQL语句与参数分离，参数作为占位符传递，数据库引擎按原样执行参数，不会解析参数中的SQL，因为参数被当作数据而非代码处理，从而避免恶意SQL逻辑执行。 - 问：ORM框架如何配置才能安全？比如MyBatis或Hibernate？
回答要点：ORM框架需配置安全选项，如自动转义用户输入（避免特殊字符影响SQL），禁用动态SQL拼接（避免用户输入拼接SQL语句），使用安全方法（如setString、setParam）传递参数，确保参数与SQL语句分离。 - 问：如何处理动态SQL？比如根据用户输入构建部分SQL？
回答要点：动态SQL需谨慎处理，若必须拼接，需对拼接部分进行转义或使用参数化查询，避免用户输入影响SQL逻辑（如用?占位符或安全函数处理拼接部分）。 - 问：输入验证和参数化查询哪个更重要？为什么？
回答要点：两者结合更有效，输入验证是第一道防线，过滤明显危险字符，减少参数化查询的负担；参数化查询是核心，能彻底防止SQL解析，即使输入验证有漏洞，参数化查询也能保证安全，但输入验证能提高效率，减少参数化查询的参数数量。
7) 【常见坑/雷区】
- 坑1：只做输入验证但未转义特殊字符。比如过滤单引号，但用户输入“' or '1'='1”时，单引号被保留，导致注入。
- 坑2：参数化查询未正确使用，比如手动拼接参数（如
sql = f"SELECT * FROM users WHERE username = '{username}'"），此时用户输入“admin' or '1'='1”会改变SQL逻辑。 - 坑3：ORM框架默认不安全，未配置安全选项。比如MyBatis默认允许动态SQL拼接，若用户输入拼接部分，会导致注入。
- 坑4：忽略隐藏输入或非表单输入（如URL参数、Cookie）。这些输入可能被用户修改，若未验证，会导致注入。
- 坑5：动态SQL拼接时未对拼接部分进行转义。比如根据用户输入构建SQL，如
sql = f"SELECT * FROM users WHERE id = {user_id}"，若user_id来自用户输入，且未转义，可能导致注入。