保护REST API/Web服务的最佳实践

在设计REST API或服务时，是否存在处理安全性(身份验证，授权，身份管理)的最佳实践？ 在构建SOAP API时，您可以使用WS-Security作为指导，有关该主题的文献很多。我发现了有关保护REST端点的更少信息。 尽管我了解REST故意没有类似于WS- *的规范，但我希望最佳实践或推荐模式已经出现。 任何有关文件的讨论或链接将非常感激。 如果它很重要，我们将使用WCF和POX/JSON序列化消息来构建使用.NET Framework v3.5构建的REST API/Services。

Github上有一个很棒的清单： 的验证

• 请勿使用Basic Auth使用标准认证(例如JWT，OAuth)。
• 不要在认证，代币生成，密码存储中重新发明轮子。使用标准。
• 在登录中使用Max Retry和jail功能。
• 在所有敏感数据上使用加密。

JWT(JSON Web令牌)

• 使用一个随机的复杂键(JWT秘密)来让暴力破解令牌变得非常困难。
• 不要从有效负载中提取算法。在后端强制执行算法(HS256或RS256)。
• 尽可能缩短令牌到期时间(TTL，RTTL)。
• 不要在JWT有效载荷中存储敏感数据，它可以被轻松解码。

的的OAuth

• 始终验证redirect_uri服务器端是否只允许列入白名单的网址。
• 总是尝试交换代码而不是代币(不允许response_type=token)。
• 使用状态参数和随机散列来防止OAuth身份验证过程中的CSRF。
• 定义默认范围，并为每个应用程序验证范围参数。

使用

• 限制请求(Throttling)以避免DDoS /强力攻击。
• 在服务器端使用HTTPS以避免MITM(中间人攻击)
• 使用带SSL的HSTS标头来避免SSL Strip攻击。

的输入

• 根据操作使用适当的HTTP方法：GET(读取)，POST(创建)，PUT/PATCH(替换/更新)和DELETE(删除记录)，如果请求的方法不是，则使用405 Method Not Allowed回应适合请求的资源。
• 根据请求验证内容类型Accept标题(内容协商)以仅允许您支持的格式(例如application/xml，application/json等)，并在406 Not Acceptable响应中回应(如果不匹配)。
• 按照您接受的方式验证发布数据的content-type(例如，application/x-www-form-urlencoded，multipart/form-data，application/json等)。
• 验证用户输入以避免常见漏洞(例如XSS，SQL注入，远程代码执行等)。
• 请勿在网址中使用任何敏感数据(凭据，密码，安全令牌或API密钥)，但请使用标准的Authorization标头。
• 使用API​​网关服务启用缓存，Rate Limit策略(例如配额，尖峰捕捉，并发速率限制)以及动态部署API资源。

的处理

• 检查所有端点是否在身份验证后受到保护，以避免身份验证过程中断。
• 应该避免用户自己的资源ID。使用/ me/orders而不是/ user/654321/orders。
• 不要自动增加ID。改为使用UUID。
• 如果您正在解析XML文件，请确保未启用实体解析以避免XXE(XML外部实体攻击)。
• 如果您正在解析XML文件，请确保实体展开未启用，以通过指数实体展开攻击来避免十亿笑/ XML炸弹。
• 使用CDN进行文件上传。
• 如果您处理大量数据，请使用工作人员和队列尽可能在后台进行处理，并快速返回响应以避免HTTP阻止。
• 不要忘记关闭 DEBUG 模式。

的输出

• 发送X-Content-Type-Options: nosniff标头。
• 发送X-Frame-Options: deny标头。
• 发送Content-Security-Policy: default-src'none'标头。
• 移除指纹标头 - X-Powered-By，Server，X-AspNet-Version等。
• 如果您返回application/json，那么您的响应内容类型为application/json。
• 强制content-type作为回应。
• 不要传回密码，密码，安全令牌等敏感数据。
• 根据完成的操作返回正确的状态码。 (例如200 OK，400 Bad Request，401 Unauthorized，405 Method Not Allowed等)。

 

https://oomake.com/question/731