在Web服务端开发中，如何防止SQL注入、XSS、CSRF等常见攻击？特别是在360的安全产品场景下，如何设计安全的API接口，确保用户数据安全？

360Web服务端开发工程师难度：中等

答案

1) 【一句话结论】
在Web服务端开发中，防止SQL注入、XSS、CSRF等攻击需采用“输入验证+输出编码+令牌机制+动态防护”的多层次策略，结合360安全产品的行为分析、动态防护技术，设计安全的API接口，确保用户数据安全。

2) 【原理/概念讲解】
老师口吻解释关键概念：

SQL注入：攻击者通过输入恶意SQL语句，绕过验证执行非法操作（如篡改数据）。防护用参数化查询（将SQL语句与参数分离，数据库解析时不会执行参数中的SQL）。类比：给数据库发指令，参数化查询是把参数像“变量”传递，数据库只处理参数值，不会执行参数中的SQL。
XSS：攻击者注入恶意脚本，在用户浏览器执行（如窃取Cookie）。防护用输入验证（检查输入是否包含脚本标签，如<script）和输出编码（将特殊字符转换为HTML实体，如<转<）。类比：输入验证是“检查输入有没有坏人”，输出编码是“把坏人变成无害的符号”。
CSRF：攻击者伪造用户请求，绕过认证（如修改密码）。防护用CSRF令牌（每个请求附带唯一令牌，服务器验证令牌有效性）。类比：给每个请求一个“身份证”，服务器检查身份证是否有效。

3) 【对比与适用场景】

攻击类型	定义	原理	常见场景	防护手段
SQL注入	恶意注入SQL语句，篡改查询结果	将用户输入拼接到SQL语句中，绕过验证执行非法操作	用户注册、登录、查询等涉及数据库的接口	参数化查询、预编译语句、白名单过滤
XSS	注入恶意脚本，在用户浏览器执行	用户输入被当作HTML/JS执行	用户评论、个人主页、表单输入等	输入验证（正则、白名单）、输出编码（HTML实体转换）
CSRF	伪造用户请求，绕过认证	攻击者诱导用户访问恶意链接，提交非法请求	修改密码、支付、删除等敏感操作	CSRF令牌、Referer检查、SameSite Cookie

4) 【示例】

SQL注入防护（参数化查询）：

# 伪代码（Python示例）
def get_user_info(user_id):
    sql = "SELECT * FROM users WHERE id = ?"  # 占位符
    params = [user_id]  # 参数单独传递
    result = db.execute(sql, params).fetchone()  # 数据库解析参数，不会执行SQL
    return result

恶意输入：1' OR '1'='1，参数化查询后，数据库解析为id = 1' OR '1'='1，不会执行。

XSS防护（输入验证+输出编码）：

# 输入验证：检查输入是否包含script标签
user_input = request.get('comment')
if '<script' in user_input:
    raise ValueError("输入包含恶意脚本")
# 输出编码：将特殊字符转换为HTML实体
safe_comment = user_input.replace('<', '&lt;').replace('>', '&gt;')
response.send(safe_comment)

CSRF防护（令牌机制）：

# 生成CSRF令牌，存储在session中
session['csrf_token'] = generate_token()
# 请求时检查令牌
def check_csrf(request):
    token = request.headers.get('X-CSRF-Token') or request.get('csrf_token')
    if token != session['csrf_token']:
        raise CSRFError("令牌无效")

5) 【面试口播版答案】
面试官您好，针对SQL注入、XSS、CSRF的防护，以及360安全产品下的API设计，我的核心思路是采用多层次安全策略。首先，SQL注入通过参数化查询（预编译语句）解决，比如把用户输入作为参数传递，数据库解析时不会执行SQL，比如用?占位符，避免字符串拼接。然后XSS通过输入验证（检查输入是否包含脚本标签）和输出编码（将特殊字符转HTML实体，如<转<），比如用户评论输入先验证，再输出时编码。CSRF用CSRF令牌，每个请求附带唯一令牌，服务器验证令牌有效性，比如在敏感操作（如修改密码）的请求头或参数中检查令牌。结合360安全产品，比如动态防护技术，通过行为分析识别异常请求（如SQL注入的异常查询模式），实时拦截。设计API时，要明确输入参数的验证规则，输出数据的编码方式，敏感操作添加CSRF令牌，同时参考360的动态防护策略，结合用户行为分析，对异常请求动态调整防护强度，确保用户数据安全。

6) 【追问清单】

问：参数化查询具体如何实现？比如不同数据库的预编译语法？
回答要点：不同数据库有不同语法（如MySQL用?，PostgreSQL用$1，SQL Server用@param），核心是将SQL和参数分离，避免拼接。
问：XSS的输入验证具体规则是什么？比如正则表达式如何写？
回答要点：使用白名单验证，只允许特定字符，比如用户名只允许字母数字，评论只允许文本，用正则过滤掉<script等标签，或允许特定标签（如<b>）但转义其他。
问：CSRF令牌的生成和验证机制？比如令牌有效期？
回答要点：令牌用随机字符串生成，存储在session中，每个请求检查请求头或参数中的令牌是否与session一致，令牌有效期通常较短（如30分钟），敏感操作需重新生成令牌。
问：360安全产品中的动态防护如何结合API安全设计？
回答要点：360的动态防护通过行为分析识别异常请求（如SQL注入的异常查询模式），实时拦截；结合API的输入验证规则，动态调整防护策略，比如对高频异常请求增加验证强度。
问：如何处理会话劫持？结合CSRF和会话管理？
回答要点：会话管理用HTTPS传输，设置Cookie的HttpOnly和Secure属性，CSRF令牌与会话绑定，防止会话劫持后伪造请求。

7) 【常见坑/雷区】

字符串拼接代替参数化查询：如sql = "SELECT * FROM users WHERE id = " + user_id，导致SQL注入。
仅做前端验证：前端可绕过，需后端验证。
CSRF令牌有效期过长：攻击者可长时间有效伪造请求。
输出编码不完整：如只编码<和>，忽略其他字符（如&，但&通常保留）。
忽略动态防护：仅依赖静态防护，未结合360行为分析识别异常请求。