随着安全成为了 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 安全实现方案。这是否够用呢？只有时间知道答案。
评论