处理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

This entry was posted in SOA. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s