针对360的数据库产品（如360DB），分析SQL注入漏洞的原理，并结合360的安全防护策略，说明如何通过数据库审计和输入验证来防止此类漏洞。

1) 【一句话结论】

SQL注入漏洞本质是用户输入未有效过滤，导致恶意SQL语句被数据库执行；针对360DB的存储过程、JSON处理等特性，通过输入验证（如参数化、JSON字段白名单）和数据库审计（日志分析+异常检测），从源头和事后监控双维度防止此类漏洞。

2) 【原理/概念讲解】

老师口吻：SQL注入的核心是“用户输入被直接拼接进SQL语句”，导致数据库执行恶意逻辑。举个例子：正常调用存储过程是EXEC sp_get_user 1，若用户输入' or '1'='1 --，拼接后变成EXEC sp_get_user ' or '1'='1 --，结果查询所有用户。类比：就像给数据库“问错问题”，把原本的“找特定用户”变成“找所有用户”。关键在于，攻击者通过特殊字符（如单引号、分号）改变SQL逻辑，绕过应用层的输入检查。更深入来说，时间盲注是通过SLEEP(5)判断执行时间，而基于错误信息的注入则是通过SQL错误提示获取信息。对于360DB，存储过程支持动态参数，若参数未验证，仍可能被注入，比如存储过程内部拼接SQL时未处理输入。

3) 【对比与适用场景】

方法	定义	特性	使用场景	注意点
输入验证	对用户输入进行合法性检查（如白名单、正则匹配、JSON字段验证）	前端/后端实时过滤，防止恶意输入进入系统	所有用户输入点（表单、API参数、JSON数据等）	需覆盖所有输入点，复杂输入（如JSON、动态SQL）可能漏，需解构后逐字段验证
数据库审计	记录数据库所有操作（SQL语句、用户、时间、执行时间）	事后追溯、检测异常SQL行为	服务器端、数据库层面（对关键操作开启）	产生大量日志，需处理性能，可能误报（如正常批量删除被误判）

4) 【示例】

伪代码示例：处理用户输入的JSON并验证字段白名单（结合360DB的JSON输入场景）。

import json
def validate_json_input(json_str, allowed_fields):
    try:
        data = json.loads(json_str)
        for field in data:
            if field not in allowed_fields:
                return False, f"字段 {field} 不在白名单内"
        return True, data
    except json.JSONDecodeError:
        return False, "输入不是有效的JSON"
# 示例：用户输入JSON，只允许id和name字段
allowed_fields = {"id", "name"}
user_input = '{"id": "1", "name": "test", "secret": "bad"}'
is_valid, result = validate_json_input(user_input, allowed_fields)
if is_valid:
    print("验证通过，数据:", result)
else:
    print("验证失败:", result)

当用户输入包含未允许的字段（如secret），验证失败，避免注入。

存储过程参数验证示例：

-- 正常调用
EXEC sp_get_user @user_id = 1;
-- 被注入的调用
EXEC sp_get_user @user_id = ' or '1'='1 --';

通过参数化（如存储过程参数绑定）避免拼接，防止注入。

5) 【面试口播版答案】

面试官您好，SQL注入的核心是用户输入未过滤，导致恶意SQL语句被数据库执行。比如用户输入' or '1'='1，拼接后查询所有用户。针对360DB，我们通过输入验证（如参数化查询、JSON字段白名单）和数据库审计（记录所有SQL操作并检测异常）来防护。输入验证方面，比如用预编译语句，把用户输入当参数，避免拼接；审计则开启数据库日志，配置规则检测异常SQL（如带单引号、复杂逻辑），这样能从源头和事后监控防止注入。具体来说，对于存储过程，需验证调用参数，避免动态拼接SQL；对于JSON输入，解构后逐字段白名单验证，确保只有允许的字段和值。

6) 【追问清单】

• 问题：如何处理JSON等复杂输入的验证？
  回答要点：解构JSON，对每个字段进行白名单验证，只允许特定字段和值范围，比如只允许id、name等字段，拒绝其他字段。
• 问题：数据库审计如何优化性能？
  回答要点：根据业务重要性，对关键表或操作开启审计，或使用采样策略，平衡监控与性能，比如只审计存储过程调用和关键查询。
• 问题：如果攻击者绕过输入验证，审计还能检测吗？
  回答要点：审计记录所有SQL，即使绕过验证，异常的SQL（如带特殊字符、复杂逻辑）会被规则检测，比如执行时间异常或错误信息，但需结合频率和逻辑分析。
• 问题：360DB的存储过程是否影响SQL注入？
  回答要点：存储过程可能封装SQL，但若参数未验证，仍可能被注入，需对存储过程调用参数进行验证，比如参数化绑定。
• 问题：输入验证中，如何处理动态SQL的拼接？
  回答要点：使用参数化查询，避免拼接；若必须拼接，需对拼接部分进行严格的正则验证，确保只包含合法字符，比如只允许数字和字母。

7) 【常见坑/雷区】

1. 忽略360DB的具体技术特性（如存储过程、JSON处理），只讲通用方法，导致回答不贴合岗位。
2. 认为输入验证能完全防止所有注入，比如时间盲注、基于错误信息的复杂注入可能绕过。
3. 审计的误报问题未说明，比如正常批量删除操作被误判为注入，未给出优化规则配置的示例。
4. 复杂输入（如JSON、动态SQL）的验证方法不具体，比如未提及解构和字段白名单的具体逻辑。
5. 未结合数据库审计日志的分析工具（如360DB自研的审计分析平台），说明如何通过日志分析检测异常，比如配置规则引擎检测异常SQL。