解释SQL注入攻击的原理，并说明在360安全产品（如360浏览器）中，如何通过技术手段（如参数化查询、预编译语句、输入过滤）来防御SQL注入，同时如何保护用户数据（如密码、隐私信息）在数据库中的存储安全（如加盐哈希、加密存储）。
答案
1) 【一句话结论】SQL注入是攻击者通过恶意构造用户输入，将非法SQL代码注入到Web应用的数据库查询中，导致数据泄露或权限提升。360通过参数化查询、预编译语句等防御技术拦截注入，同时采用加盐哈希、加密存储等方式保护用户密码等敏感数据在数据库中的安全。
2) 【原理/概念讲解】老师口吻，解释SQL注入原理：当Web应用将用户输入直接拼接进SQL语句时，攻击者可构造包含特殊SQL字符（如单引号、分号）或逻辑条件的输入，使数据库执行非预期查询。例如，登录接口的SQL为SELECT * FROM users WHERE username='user_input' AND password='pass_input'，若用户输入' or '1'='1'作为用户名，拼接后SQL变为SELECT * FROM users WHERE username='' or '1'='1' AND password='pass_input'，因'1'='1'恒成立，查询返回所有用户数据。
防御手段方面，参数化查询（预编译语句）将SQL与参数分离，数据库先编译SQL结构再绑定参数，输入不会被当作SQL代码执行；输入过滤是对用户输入进行字符过滤（如过滤单引号），但存在绕过风险（如编码绕过）；保护存储时，密码等敏感数据用加盐哈希（如bcrypt），通过随机盐值和多次哈希，即使哈希泄露也无法还原原始密码；隐私数据用加密存储（如AES-256），但需注意密钥安全管理。
3) 【对比与适用场景】
| 方法 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 参数化查询 | 将SQL与参数分离，参数作为独立对象传递 | 防御注入能力强，数据库自动处理参数，不会拼接 | Web应用数据库查询（用户输入相关） | 需支持预编译的数据库（MySQL/PostgreSQL/SQL Server） |
| 预编译语句 | 数据库预编译SQL，参数动态绑定 | 同参数化查询，防御注入，性能较好 | 高并发数据库操作（如登录、查询） | 复杂查询（如子查询）支持良好 |
| 输入过滤 | 对用户输入过滤危险字符（如单引号） | 简单易实现，但易被绕过 | 安全性要求不高的场景（辅助手段） | 需精心设计过滤规则，否则易被绕过 |
| 加盐哈希 | 密码添加随机盐值后哈希 | 哈希不可逆，盐值随机，防彩虹表 | 密码存储（如用户登录） | 需强哈希算法（如bcrypt）和随机盐生成 |
| 加密存储 | 敏感数据加密后存储 | 存储时加密，解密后注意安全 | 非密码类敏感数据（如个人信息） | 需安全加密算法（如AES-256）和密钥管理 |
4) 【示例】
正常登录逻辑（存在注入风险）：
// PHP+MySQL，拼接用户输入
$username = $_GET['username'];
$password = $_GET['password'];
$sql = "SELECT * FROM users WHERE username='$username' AND password='$password'";
$result = $conn->query($sql);
当用户输入username='admin' or '1'='1'，password='anything'时，SQL变为：
SELECT * FROM users WHERE username='admin' or '1'='1' AND password='anything'
因'1'='1'为真，返回所有用户数据。
参数化查询（防御注入）：
$username = $_GET['username'];
$password = $_GET['password'];
$stmt = $conn->prepare("SELECT * FROM users WHERE username=? AND password=?");
$stmt->bind_param("ss", $username, $password); // 参数绑定
$stmt->execute();
$result = $stmt->get_result();
无论输入如何，数据库仅将参数视为数据，不会执行恶意SQL。
5) 【面试口播版答案】
“面试官您好，SQL注入攻击的原理是攻击者通过构造包含恶意SQL代码的用户输入，让Web应用将这部分代码直接拼接进数据库查询语句中，从而绕过应用层验证，执行非预期操作。比如一个登录接口，原本的SQL是SELECT * FROM users WHERE username='user' AND password='pass'，如果用户输入' or '1'='1'作为用户名，那么拼接后的SQL变成SELECT * FROM users WHERE username='' or '1'='1' AND password='pass'，这样查询会返回所有用户数据，这就是SQL注入。
在360安全产品中，我们主要通过参数化查询（预编译语句）来防御，比如将用户输入作为参数传递，数据库引擎先编译SQL结构，再绑定参数，这样输入不会被当作SQL代码执行。同时，输入过滤作为辅助手段，对用户输入进行白名单过滤，但更推荐参数化查询。对于用户数据存储安全，比如密码，我们采用加盐哈希的方式，比如使用bcrypt算法，先给密码添加随机盐值，再进行多次哈希处理，这样即使数据库被泄露，攻击者也无法通过彩虹表还原原始密码。对于其他隐私信息，比如用户个人信息，我们采用加密存储，比如AES-256加密，但要注意密钥的安全管理，避免密钥泄露导致数据被解密。”
6) 【追问清单】
- 问题1：参数化查询和预编译语句有什么区别？为什么预编译语句在360中更常用？
回答要点：参数化查询和预编译语句本质类似，但预编译语句更强调数据库先编译SQL结构，参数动态绑定，在处理复杂查询（如子查询、动态SQL）时性能更好，且更符合高并发场景下的数据库操作，360的数据库服务（如MySQL集群）支持预编译，因此常用预编译。 - 问题2：输入过滤为什么不如参数化查询有效？有没有什么场景下需要用输入过滤？
回答要点：输入过滤通过过滤危险字符（如单引号、分号）来防御注入，但存在绕过风险（如编码绕过、利用SQL函数绕过），只有在参数化查询不可用（如老旧数据库）或作为辅助手段时，才会使用输入过滤。 - 问题3：加盐哈希中的盐值如何生成？为什么不能重复使用同一个盐值？
回答要点：盐值需随机生成，且每个密码对应唯一盐值，通常使用加密安全随机数生成器（如PHP的random_bytes）生成。若重复使用盐值，相同密码的哈希值相同，攻击者可通过彩虹表快速破解，因此必须保证盐值的唯一性和随机性。 - 问题4：加密存储的密钥管理需要注意什么？如果密钥泄露了怎么办？
回答要点：加密密钥需妥善管理（如使用密钥管理系统KMS），避免硬编码在代码中。若密钥泄露，需立即更新密钥，并对受影响的数据重新加密（若可能），同时通知用户潜在风险。 - 问题5：除了数据库，SQL注入还会影响其他组件吗？比如前端或后端的其他逻辑？
回答要点：SQL注入主要针对数据库查询，但也会影响依赖数据库查询的其他组件（如缓存系统、日志系统），因此需整体考虑安全设计，确保所有涉及数据库查询的环节都进行防御。
7) 【常见坑/雷区】
- 坑1：混淆参数化查询和手动输入过滤，认为输入过滤足够。实际上，输入过滤存在绕过风险，而参数化查询是更可靠的防御手段。
- 坑2：忘记加盐哈希的重要性，只说哈希。若使用普通哈希（如MD5、SHA-1），即使加盐，也可能被彩虹表破解，因此必须使用加盐哈希算法（如bcrypt）。
- 坑3：混淆预编译和动态SQL拼接，认为动态SQL拼接也可以防御。实际上，动态SQL拼接若未正确处理用户输入，仍存在注入风险，必须使用参数化查询。
- 坑4：忽略加密存储的密钥安全。若密钥管理不当，加密存储就失去意义，攻击者可通过获取密钥解密数据。
- 坑5：认为SQL注入只针对数据库，其他组件（如文件系统、API）也有风险。比如，攻击者可通过注入文件路径（如文件包含漏洞）执行恶意代码，因此需全面考虑安全风险。