安全

[TOC] >[参考](http://restful.p2hp.com/learn/security-essentials) ## 安全设计原则 最小权限 * 实体应该只具有所需的权限集来执行授权的操作，而不再执行。可以根据需要添加权限，并在不再使用时撤消。 失败保护默认值 * 用户对系统中任何资源的默认访问级别应被“拒绝”，除非他们已明确授予“许可”。 机制经济 * 设计应尽可能简单。所有组件接口和它们之间的交互应该足够简单易懂。 完全中介 * 系统应验证其所有资源的访问权限，以确保它们被允许且不应依赖缓存的权限矩阵。如果正在撤消对给定资源的访问级别，但未在权限矩阵中反映，则会违反安全性。 开放式设计 * 该原则强调了以开放的方式构建系统的重要性 - 没有秘密的机密算法。 权限分离 * 授予实体权限不应完全基于单一条件，基于资源类型的条件组合更好。 最不常见的机制 * 它涉及在不同组件之间共享状态的风险。如果可以破坏共享状态，则可以破坏依赖于它的所有其他组件。 心理可接受性 * 它指出安全机制不应使资源更难以访问，而不是安全机制不存在。简而言之，安全性不应该使用户体验变得更糟。 ## 最佳实践 1. 把事情简单化 2. 始终使用HTTPS 通过始终使用SSL，可以将身份验证凭据简化为随机生成的访问令牌，该令牌在HTTP Basic Auth的用户名字段中提供。它使用起来相对简单，您可以免费获得许多安全功能。 - 如果使用HTTP 2来提高性能 - 您甚至可以通过单个连接发送多个请求，这样就可以避免以后的请求产生完整的TCP和SSL握手开销。 3. 使用密码哈希 4. 永远不要公开URL的信息 用户名，密码，会话令牌和API密钥不应出现在URL中，因为这可以在Web服务器日志中捕获，这使它们很容易被利用。 如`https://api.domain.com/user-management/users/{id}/someAction?apiKey=abcd123456789 /` 5. 考虑一下OAuth 虽然[基本身份验证](https://en.wikipedia.org/wiki/Basic_access_authentication)对于大多数API都足够好，但如果正确实现，它也是安全的 - 但您也可能想要考虑[OAuth](https://tools.ietf.org/html/rfc6749)。OAuth 2.0授权框架允许第三方应用程序通过编排资源所有者和HTTP服务之间的批准交互，或者通过允许第三方应用程序来代表资源所有者获得对HTTP服务的有限访问权限以自己的名义获取访问权限。 6. 考虑在请求中添加时间戳 与其他请求参数一起，您可以在API请求中将请求时间戳添加为HTTP自定义标头。服务器会将当前时间戳与请求时间戳进行比较，并且只有在合理的时间范围内（可能是1-2分钟）才接受请求。 这将阻止那些试图在不更改此时间戳的情况下强行执行系统的人进行非常基本的重播攻击。 7. 输入参数验证 在到达应用程序逻辑之前，在第一步验证请求参数。如果验证失败，请进行强有力的验证检查并立即拒绝请求。在API响应中，发送相关的错误消息和正确输入格式的示例以改善用户体验。