随着安全成为了 SOA 实现的主要宗旨之一,以及 REST 迅速成为流行的 SOA 实现方案之一,关于 REST 安全成为了及时的话题。根据 Chris Comerford 以及 Pete Soderling 的说法,REST 开发对于安全的处理还不够:
- REST 没有预定义的安全方法来让开发者定义它们自己的,同时
- 通常,开发者急于得到…所部署的服务并不像对待 web 应用一样用同样的勤劳对待他们。
Comerford 与 Soderling 继续进行了解释,因为 REST 是基于 HTTP 的,而 REST 服务有跟标准的 web 应用一样的容易受攻击的倾向。包括被破坏的验证,注入攻击,跨站点的脚本以及跨站点的请求伪造。此外,REST 服务还有其独特的安全弱点,例如:
- Mashup 相关的问题: > …一个从多个 API 拉取数据的 mashup 可能会要求用户名和密码。而验证终端用户的授信取决于 mashup 的提供者。终端用户必须相信 mashup 的提供者不会偷窃 (或者由于疏忽而泄露) 他们的授信,而 API 的提供者也必须相信 mashup 的提供者可以审核和验证这一用户的帐号,不是一个黑客或者恶意的用户。
- 不成熟的草根协议: > OAuth 1.0…容易遭受会话完成攻击,并且可能造成让攻击者盗取 API 终端用户个人身份的结果。
幸运的是,许多 HTTP 安全实践都可以有效的应用于 REST 服务,Comerford 和 Soderling 推荐遵循如下的几条规则:
- 为你的 API 启用其它任何你的组织已部署的 web 应用同样的安全机制。比如说,如果你在 web 前端过滤 XSS,你必须对你的 API 也这样做,最好是使用同样的工具。
- 不要使用你自己的安全。使用那些被互审过测试过的框架或现有的包…
- 除非你的 API 是一个免费的,只读的公开 API,否则不要使用单一的基于密钥的验证。这不够,需要加上密码要求。
- 不要放过未加密的静态密钥。如果你使用基本的 HTTP 并且在线路上发送的,请加密。
- 理想的情况下,使用基于哈布的消息验证码 (HMAC),因为它最安全。
K. Scott Morrison 进一步阐释了与 REST 安全相关的事务:
REST 缺乏良好表达的安全模型…由于它草根的天性,在安全方面往往受到忽视——“像 web 一样做就好了”,这样当然没有任何好处…REST 风格的流行要归因于它的简单和快速实现,特别是当面对让人兴趣全无的复杂性以及对工具要求极高的 WS-* 栈的时候。可以想象得到为了向完成应用而全力冲刺,安全相关的问题自然而然的就被忽视或者完全忘掉了。
Morrison 同时再次肯定了 REST 服务可以做到安全,并且展示了 Comerford 以及 Soderling 的部分推荐可以如何利用 SecureSpan 网关来实现,通过配置策略,可以保证对于服务的访问要求使用基于组成员 SSL 以及授权服务访问。此外,SecureSpan 可以配置而实现扫描跨站点,PHP 以及 shell 注入攻击。
REST 不像 WS* 那样指定了定义良好的专为 web 服务构建的独立于协议的安全模型,目前它并没有自己的安全模型。作为代替,现在的 REST 安全最佳实践是利用了现有的 HTTP 安全实现方案。这是否够用呢?只有时间知道答案。
评论