保护 REST API / 网络服务的最佳做法

在设计 REST API 或服务时,是否存在用于处理安全性(身份验证,授权,身份管理)的最佳实践?

在构建 SOAP API 时,您以 WS-Security 为指南,并且有关该主题的文献很多。我发现有关保护 REST 端点的信息较少。

虽然我了解 REST 故意没有类似于 WS- * 的规范,但我希望出现了最佳实践或推荐的模式。

任何讨论或相关文件的链接将不胜感激。如果重要的话,我们将使用 WCF 和 POX / JSON 序列化消息来使用. NET Framework v3.5 构建的 REST API / 服务。

答案

正如 tweakt 所说,Amazon S3 是一个很好的模型。他们的请求签名确实具有某些功能(例如包含时间戳),可以防止意外和恶意的请求重播。

HTTP Basic 的好处是几乎所有 HTTP 库都支持它。当然,在这种情况下,您将需要 SSL,因为通过网络发送纯文本密码几乎是一件坏事。使用 SSL 时,Basic 比 Digest 更好,因为即使调用者已经知道需要凭据,Digest 也需要进行额外的往返来交换现时值。使用 Basic,呼叫者只需在第一时间发送凭据即可。

一旦建立了客户端的身份,授权实际上只是一个实现问题。但是,您可以将授权委托给具有现有授权模型的其他组件。再次,关于 Basic 的好处是,您的服务器最终带有客户端密码的纯文本副本,您可以根据需要将其简单地传递到基础结构中的另一个组件。

除 HTTP 外,没有其他针对 REST 的标准。那里已经建立了 REST 服务。我建议您看一看它们,并了解它们的工作原理。

例如,在开发自己的产品时,我们从 Amazon 的 S3 REST 服务中借鉴了很多想法。但是我们选择不使用基于请求签名的更高级的安全模型。更简单的方法是基于 SSL 的 HTTP 基本认证。您必须决定哪种方法最适合您的情况。

另外,我强烈推荐 O'reilly 的书RESTful Web Services 。它解释了核心概念,并提供了一些最佳实践。通常,您可以采用他们提供的模型并将其映射到您自己的应用程序。

您可能还想看看OAuth ,这是一种新兴的开放协议,用于基于令牌的授权,专门针对 http api。

它与flickr所采取的方法非常相似, 请记住牛奶 “休息” api(不一定是静态 api 的好例子,而是基于令牌的方法的好例子)。

Github上有一个很棒的清单:

认证方式

  • 不要在身份验证,令牌生成,密码存储方面重蹈覆辙。使用标准。

  • 在 “登录” 中使用 “ Max Retry和 “监禁” 功能。

  • 对所有敏感数据使用加密。

JWT(JSON Web 令牌)

  • 使用随机的复杂密钥(JWT Secret)使暴力破解令牌变得非常困难。

  • 不要从有效载荷中提取算法。在后端(HS256 或 RS256)中强制使用算法。

  • 使令牌到期时间( TTLRTTL )尽可能短。

  • 不要将敏感数据存储在JWT有效负载中,可以轻松对其进行解码。

OAuth

  • 始终在服务器端验证redirect_uri以仅允许列入白名单的 URL。

  • 始终尝试交换代码而不是令牌(不允许response_type=token )。

  • 将状态参数与随机哈希一起使用可防止CSRF进入OAuth身份验证过程。

  • 定义默认范围,并验证每个应用程序的范围参数。

访问

  • 限制请求(限制)以避免 DDoS / 暴力攻击。

  • 在服务器端使用 HTTPS 避免 MITM(中间人攻击)

  • HSTS标头与 SSL 配合使用可避免 SSL Strip 攻击。

输入值

  • 根据操作使用正确的 HTTP 方法: GET (读取), POST (创建), PUT/PATCH (替换 / 更新)和DELETE (删除记录),如果请求的方法不是405 Method Not Allowed不适合所请求的资源。

  • 根据请求验证内容类型的Accept标头(内容协商)以仅允许您支持的格式(例如application/xmlapplication/json等),如果不匹配,则以406 Not Acceptable响应进行响应。

  • 接受时验证发布数据的content-type (例如application/x-www-form-urlencodedmultipart/form-dataapplication/json等)。

  • 验证用户输入以避免常见漏洞(例如 XSS,SQL 注入,远程代码执行等)。

  • 请勿在 URL 中使用任何敏感数据(凭证,密码,安全令牌或 API 密钥),而应使用标准的Authorization标头。

  • 使用 API 网关服务来启用缓存, Rate Limit策略(例如,配额,秒杀,并行速率限制)并动态部署 API 资源。

处理中

  • 检查是否所有端点都在身份验证后受到保护,以避免破坏身份验证过程。

  • 应避免使用用户自己的资源 ID。使用 / me / orders 而不是 / user / 654321 / orders。

  • 不要自动增加 ID。请改用 UUID。

  • 如果要解析 XML 文件,请确保未启用实体解析,以避免 XXE(XML 外部实体攻击)。

  • 如果要解析 XML 文件,请确保未启用实体扩展,以避免通过指数实体扩展攻击引起 Billion Laughs / XML 炸弹。

  • 使用 CDN 进行文件上传。

  • 如果您要处理大量数据,请使用 Workers 和 Queues 在后台尽可能多地处理并快速返回响应以避免 HTTP 阻塞。

  • 不要忘记关闭调试模式。

输出量

  • 发送X-Content-Type-Options: nosniff标头。

  • 发送X-Frame-Options: deny标头。

  • 发送Content-Security-Policy: default-src 'none'标头。

  • 删除指纹标头X-Powered-ByServerX-AspNet-Version

  • 强制响应content-type ,如果返回application/json则响应内容类型为application/json

  • 不要返回敏感数据,例如凭据,密码,安全令牌。

  • 根据完成的操作返回正确的状态码。 (例如200 OK400 Bad Request401 Unauthorized405 Method Not Allowed等)。

我很惊讶尚未提到带有客户端证书的 SSL。当然,只有当您可以依靠证书标识的用户社区时,这种方法才真正有用。但是许多政府 / 公司确实将它们发布给用户。用户不必担心会创建另一个用户名 / 密码组合,并且在每个连接上都建立了身份,因此与服务器的通信可以完全是无状态的,不需要用户会话。 (并不意味着提到的任何 / 所有其他解决方案都需要会话)

这些答案中的每个人都忽略了真正的访问控制 / 授权。

例如,如果您的 REST API / Web 服务与 POST / GET 病历有关,则您可能需要定义关于谁可以访问数据以及在什么情况下可以访问的访问控制策略。例如:

  • 医生可以获取与其有护理关系的患者的病历
  • 没有人可以在工作时间以外发布医疗数据(例如 9 到 5)
  • 最终用户可以获取自己拥有的医疗记录或监护人的医疗记录
  • 护士可以更新与护士属于同一单位的患者的病历。

为了定义和实现这些细粒度的授权,您将需要使用称为 XACML 的基于属性的访问控制语言,即可扩展访问控制标记语言。

这里的其他标准适用于以下方面:

  • OAuth:ID。联盟和授权委派,例如让某项服务代表我代表另一项服务(Facebook 可以发布到我的 Twitter)
  • SAML:身份联合 / Web SSO。 SAML 与用户身份有关。
  • WS-Security / WS- * 标准:这些标准着重于 SOAP 服务之间的通信。它们特定于应用程序级消息传递格式(SOAP),并且涉及消息传递的各个方面,例如可靠性,安全性,机密性,完整性,原子性,事件性... 没有一个涉及访问控制,并且都特定于 SOAP。

XACML 与技术无关。它可以应用于 Java 应用程序,.NET,Python,Ruby ... Web 服务,REST API 等。

以下是有趣的资源:

我使用过 OAuth 几次,还使用了其他一些方法(BASIC / DIGEST)。我全力建议 OAuth。以下链接是我使用 OAuth 看到的最好的教程:

http://hueniverse.com/oauth/guide/

关于Rain 的安全性方面,我见过的最好的帖子之一已经在1 RainDrop 上结束了 。 MySpace API 还将 OAuth 用于安全性,您可以在 RestChess 代码中完全访问其自定义渠道,对此我进行了很多研究。这是在 Mix 上演示的,您可以在此处找到发布内容。

感谢您的出色建议。我们最终使用了自定义 HTTP 标头将身份令牌从客户端传递到服务,以准备将 RESTful API 与即将推出的 Microsoft Zermatt Identity 框架集成。我所描述的问题, 在这里和我们的解决方案在这里 。我还接受了tweakt的建议,并购买了RESTful Web 服务 - 如果您要构建任何类型的 RESTful API,这是一本非常不错的书。

OWASP(开放 Web 应用程序安全项目)具有一些备忘单,涉及 Web 应用程序开发的所有方面。该项目是非常有价值和可靠的信息来源。关于 REST 服务,您可以检查以下内容: https : //www.owasp.org/index.php/REST_Security_Cheat_Sheet