设计API接口的安全防护措施，针对360安全产品，如何防止DDoS攻击、SQL注入、API滥用？请说明负载均衡器的限流、WAF（Web应用防火墙）、输入验证、签名验证等方案。
360Web服务端开发工程师-AI方向难度：中等
答案
1) 【一句话结论】针对360安全产品的API防护，需构建多层次的纵深防御体系，结合负载均衡器限流（网络层）、WAF（应用层）过滤恶意请求、输入验证（业务层）过滤非法参数、签名验证（业务层）确保请求合法性，从网络、应用、业务多维度抵御DDoS、SQL注入、API滥用等攻击。
2) 【原理/概念讲解】
老师讲解：
- 负载均衡器限流：负载均衡器（如Nginx、F5）部署在API网关前，通过配置连接数、请求速率等参数，限制单个IP或用户的并发请求和单位时间内的请求数。类比：像交通路口的限速和限流，防止车辆拥堵导致道路瘫痪，这里防止DDoS攻击时大量请求淹没服务器。
- WAF（Web应用防火墙）：部署在负载均衡器后或直接在应用服务器前，通过预定义的规则库（如SQL注入、XSS、CC攻击等）过滤恶意请求，拦截或重定向非法流量。类比：像机场的安检，检查乘客的行李和证件，阻止携带危险物品的乘客进入，这里阻止恶意请求进入应用。
- 输入验证：在业务逻辑层对用户输入的参数（如用户名、密码、查询参数）进行类型、格式、长度等校验，过滤SQL注入、XSS等攻击。类比：像银行柜员的身份核验，检查客户的身份证和业务单据，防止伪造或非法操作，这里验证输入参数的合法性。
- 签名验证：为API请求生成签名（如基于时间戳、密钥、请求参数的HMAC），客户端在请求中携带签名，服务器验证签名有效性，确保请求的完整性和来源合法性。类比：像合同签署的验证，双方通过密钥验证合同的真伪，防止篡改或伪造，这里验证请求的来源和内容未被篡改。
3) 【对比与适用场景】
| 技术方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 负载均衡器限流 | 负载均衡器通过配置连接数、请求速率等参数，限制请求流量 | 网络层，对IP或用户进行速率限制 | 防御DDoS攻击，控制并发请求 | 需结合业务逻辑，避免误限正常用户 |
| WAF | 部署在应用前，通过规则库过滤恶意请求 | 应用层，基于规则匹配拦截 | 防御SQL注入、XSS、CC攻击等 | 规则需定期更新，避免误报/漏报 |
| 输入验证 | 业务层对输入参数进行校验 | 逻辑层，过滤非法输入 | 防止SQL注入、参数篡改 | 验证需全面，覆盖所有输入点 |
| 签名验证 | 生成请求签名，客户端携带，服务器验证 | 业务层，确保请求完整性和来源 | 防止API滥用、请求伪造 | 签名需包含时间戳，防止重放攻击 |
4) 【示例】
- 负载均衡器限流配置（Nginx示例）：
（解释：限制每个IP每秒最多1个请求，突发5个，不延迟，防止DDoS时请求堆积）limit_req_zone $binary_remote_addr zone=per_ip:10m rate=1r/s; server { listen 80; location /api/ { limit_req zone=per_ip burst=5 nodelay; # 后续路由到后端服务 } } - 输入验证（Python伪代码）：
def validate_input(param): if not isinstance(param, str) or len(param) > 100: raise ValueError("输入参数非法") # 防止SQL注入：过滤特殊字符 param = param.replace(';', '').replace('--', '') return param - 签名验证（请求示例）：
请求头包含签名：
服务器验证：POST /api/data HTTP/1.1 Host: api.360.com Authorization: signature=HMAC-SHA256(123456, "timestamp=1672531200,api_key=abcde,query=example")import hmac, hashlib key = "123456" expected = hmac.new(key.encode(), b"timestamp=1672531200,api_key=abcde,query=example", hashlib.sha256).hexdigest() if expected == request.headers['Authorization'].split('=')[1]: # 验证通过
5) 【面试口播版答案】
“针对360安全产品的API防护，需构建多维度防御体系。首先，负载均衡器限流，通过配置请求速率限制（如每秒1个请求），防止DDoS攻击时流量淹没服务器；其次，WAF部署在应用前，通过规则库拦截SQL注入、XSS等恶意请求；然后，业务层输入验证，对用户输入参数进行类型和格式校验，过滤非法输入；最后，签名验证，为请求生成基于时间戳、密钥的签名，客户端携带，服务器验证，确保请求完整性和来源合法性。这些措施从网络、应用、业务层协同，有效抵御DDoS、SQL注入、API滥用。”
6) 【追问清单】
- 问：负载均衡器的限流参数如何设置？
答：需结合业务QPS（每秒请求数），比如正常业务QPS为100，限流设置为1-5倍，突发时允许少量超量，避免误限正常用户。 - 问：WAF的规则如何更新？
答：定期从安全厂商（如360 WAF）获取规则库更新，结合业务特征调整规则，避免误报（如正常业务请求被拦截）或漏报（如新型攻击）。 - 问：输入验证的深度如何？
答：需覆盖所有输入点，包括路径参数、查询参数、请求体，对敏感参数（如密码、数据库查询）进行强校验（如密码长度、格式），防止SQL注入。 - 问：签名验证的时间戳如何处理？
答：时间戳设置有效期（如5分钟），防止重放攻击，同时结合IP地址或用户标识，增强验证安全性。 - 问：如何处理限流后的流量？
答：将限流后的流量重定向到缓存或降级服务，避免影响用户体验，同时记录限流日志，分析攻击特征。
7) 【常见坑/雷区】
- 限流仅限网络层，忽略业务层：只配置负载均衡器限流，业务层未做验证，导致恶意请求绕过限流。
- WAF规则误报：规则库过时或业务特征未匹配，正常请求被拦截，影响业务。
- 输入验证不全面：只验证部分输入参数，遗漏关键参数（如数据库查询参数），导致SQL注入。
- 签名验证未包含时间戳：允许重放攻击，攻击者可以缓存合法请求并重放，绕过验证。
- 忽略API密钥的轮换：密钥长期未更换，被泄露后导致API滥用，攻击者可伪造请求。