处理REST服务安全

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

查看英文原文：Dealing with REST Services Security