铁路客票系统的API接口（如购票、退票）需防止常见攻击（如SQL注入、越权访问），请设计API安全防护方案，包括输入验证、认证（OAuth2/JWT）、授权（RBAC）、限流、防重放攻击，并说明如何实现API网关的防护。
中国铁路信息科技集团有限公司网络安全技术研究1难度：中等
答案
1) 【一句话结论】：铁路客票系统API需通过“输入验证+认证+授权+限流+防重放”分层防护，结合API网关实现安全闭环，核心是“输入-认证-授权-防护-网关”的协同设计，全面抵御常见攻击。
2) 【原理/概念讲解】：
- 输入验证：防止SQL注入等攻击，需对输入参数做白名单校验（如日期用正则
^\d{4}-\d{2}-\d{2}$、座位类型限定“一等座”“二等座”），并用参数化查询（避免拼接SQL）或ORM框架（如MyBatis）防止SQL注入。 - 认证（OAuth2/JWT）：
- OAuth2：采用授权码模式，用户登录后通过授权服务器获取访问令牌（Access Token），令牌由授权服务器颁发，需定期刷新（Refresh Token）。
- JWT：自包含的签名令牌，包含用户ID、过期时间（
exp）、签名（signature），通过验证签名和exp确保令牌有效性。
- 授权（RBAC）：基于角色（Role-Based Access Control）模型，将用户角色（如“售票员”“退票员”）与接口权限绑定（如“购票员”有“购票”权限，“退票员”有“退票”权限），通过角色继承控制权限范围。
- 限流：采用令牌桶算法（Token Bucket），控制请求速率（如每分钟10次），防止DDoS攻击，同时记录异常请求用于后续分析。
- 防重放攻击：使用随机nonce（随机数）+时间戳，确保请求唯一性（如nonce每请求生成一次，时间戳需在合理范围内，如5分钟内）。
3) 【对比与适用场景】：
| 对比项 | OAuth2 | JWT |
|---|---|---|
| 定义 | 授权框架，通过令牌授权第三方应用 | 自包含的JSON Web Token，包含声明 |
| 特性 | 有令牌管理（刷新令牌），适合第三方登录 | 无状态，自包含，适合无状态服务 |
| 使用场景 | 第三方应用调用API（如微信登录后调用购票接口） | 后端服务间通信，或单点登录后API调用 |
| 注意点 | 需管理令牌生命周期，防止泄露 | 过期时间设置合理，防止过期后重放 |
| 对比项 | RBAC | ABAC |
|---|---|---|
| 定义 | 基于角色（Role-Based Access Control） | 基于属性（Attribute-Based Access Control） |
| 特性 | 角色固定，权限集中管理 | 权限基于用户属性（如部门、职位、时间） |
| 使用场景 | 铁路系统固定角色（如售票员、退票员） | 更灵活的场景（如根据用户等级调整权限） |
| 注意点 | 角色继承需谨慎，避免权限越权 | 属性数据需实时更新 |
4) 【示例】：以“购票”API为例，请求示例（POST /api/v1/tickets）：
{
"train_id": "G101",
"date": "2024-05-20",
"passenger_id": "123456",
"seat_type": "二等座"
}
处理流程：
- 输入验证：检查
train_id（非空、格式校验）、date（日期格式）、passenger_id（长度校验）、seat_type（白名单“一等座”“二等座”）。 - 认证：验证请求头
Authorization: Bearer <jwt_token>，解析JWT，验证签名（exp检查是否过期）。 - 授权：从JWT中获取用户角色（如“普通用户”），检查该角色是否有“购票”权限（通过RBAC规则）。
- 限流：检查API网关令牌桶，当前用户请求速率是否超过阈值（如每分钟10次）。
- 防重放：检查请求头
nonce（随机数）是否与之前请求匹配，或时间戳是否在5分钟内。 - 通过所有检查后，调用后端服务处理购票逻辑。
5) 【面试口播版答案】：各位面试官好，针对铁路客票系统的API安全防护，我的方案核心是“分层防护+API网关”的闭环设计。首先，输入验证方面，对购票、退票等接口的参数做白名单校验（比如日期用正则^\d{4}-\d{2}-\d{2}$、座位类型限定“一等座”“二等座”），并用参数化查询防止SQL注入。然后认证采用OAuth2授权码模式，用户登录后获取访问令牌，通过JWT签名验证确保令牌有效性（包含过期时间exp）。授权采用RBAC模型，将用户角色（如“售票员”）与权限（“购票”“退票”）绑定，确保角色只能访问对应接口。限流用令牌桶算法控制请求速率（比如每分钟10次），防止DDoS攻击。防重放通过随机nonce+时间戳，确保请求唯一性。最后，所有API通过API网关统一防护，网关负责输入验证、认证、授权、限流、防重放，同时记录日志便于审计。这样能全面覆盖常见攻击，保障系统安全。
6) 【追问清单】：
- 问：OAuth2的刷新令牌如何管理？答：刷新令牌需存储在安全的地方（如Redis），设置合理过期时间（如7天），定期轮换，防止泄露。
- 问：JWT的过期时间如何设置？答：根据业务需求，比如1小时过期，超时后用户需重新登录获取新令牌。
- 问：RBAC的权限粒度如何细化？答：按功能模块划分角色（如“购票员”“退票员”“管理员”），每个角色对应具体接口权限，避免权限越权。
- 问：限流策略如何平衡安全与用户体验？答：采用阶梯式限流（正常用户低阈值，异常用户高阈值），并记录异常请求用于后续分析。
- 问：API网关的具体实现技术？答：可选用Kong、Apigee等开源网关，或自研基于Nginx+Lua的网关，实现上述防护功能。
7) 【常见坑/雷区】：
- 输入验证只做黑名单（如过滤单引号），未用参数化查询，可能被SQL注入绕过。
- 认证只验证签名，未检查令牌有效期，可能导致过期令牌被重用。
- 授权未考虑角色继承，导致子角色拥有父角色的权限（如“售票员”子角色有“退票”权限）。
- 限流策略过于严格，影响正常用户购票体验（如限流到每分钟5次，导致高峰期无法购票）。
- 防重放只检查时间戳，未使用nonce，可能被重放攻击（如攻击者重复发送相同请求）。