HTML5安全风险详析之一：CORS攻击

CORS-CrossOrigin Resources Sharing，也即跨源资源共享，它定义了一种浏览器和服务器交互的方式来肯定是否容许跨域请求。它是一个妥协，有更大的灵活性，但比起简单地容许全部这些的要求来讲更加安全。简言之，CORS就是为了让AJAX能够实现可控的跨域访问而生的。

 

1、从SOP到CORS

SOP就是Same Origin Policy同源策略，指一个域的文档或脚本，不能获取或修改另外一个域的文档的属性。也就是Ajax不能跨域访问，咱们以前的Web资源访问的根本策略都是创建在SOP上的。它致使不少web开发者很痛苦，后来搞出不少跨域方案，好比JSONP和flash socket。以下图所示：

后来出现了CORS-CrossOrigin Resources Sharing，也即跨源资源共享，它定义了一种浏览器和服务器交互的方式来肯定是否容许跨域请求。它是一个妥协，有更大的灵活性，但比起简单地容许全部这些的要求来讲更加安全。简言之，CORS就是为了让AJAX能够实现可控的跨域访问而生的。具体能够参见个人这篇文章《HTML5安全：CORS（跨域资源共享）简介》。示意以下图所示：

如今W3C的官方文档目前仍是工做草案，可是正在朝着W3C推荐的方向前进。不过目前许多现代浏览器都提供了对它的支持。

服务器端对于CORS的支持，主要就是经过设置Access-Control-Allow-Origin来进行的。若是浏览器检测到相应的设置，就能够容许Ajax进行跨域的访问。例如：

Access–Control-Allow-Origin: http://blog.csdn.net

应用CORS的系统目前包括Face.com、GoogleCloudStorage API等，主要是为开放平台向第三方提供访问的能力。

2、CORS带来的风险

CORS很是有用，能够共享许多内容，不过这里存在风险。由于它彻底是一个盲目的协议，只是经过HTTP头来控制。

它的风险包括：

一、HTTP头只能说明请求来自一个特定的域，可是并不能保证这个事实。由于HTTP头能够被伪造。

因此未经身份验证的跨域请求应该永远不会被信任。若是一些重要的功能须要暴露或者返回敏感信息，应该须要验证Session ID。

二、第三方有可能被入侵

举一个场景，FriendFeed经过跨域请求访问Twitter，FriendFeed请求tweets、提交tweets而且执行一些用户操做，Twitter提供响应。二者都互相相信对方，因此FriendFeed并不验证获取数据的有效性，Twitter也针对Twitter开放了大部分的功能。

可是当若是Twitter被入侵后：

FriendFeed老是从Twitter获取数据，没有通过编码或者验证就在页面上显示这些信息。可是Twitter被入侵后，这些数据就多是有害的。

或者FriendFeed被入侵时：

Twitter响应FriendFeed的请求，例如发表Tweets、更换用户名甚至删除帐户。当FriendFeed被入侵后，攻击者能够利用这些请求来篡改用户数据。

因此对于请求方来讲验证接收的数据有效性和服务方仅暴露最少最必须的功能是很是重要的。

三、恶意跨域请求

即使页面只容许来自某个信任网站的请求，可是它也会收到大量来自其余域的跨域请求。.这些请求有时可能会被用于执行应用层面的DDOS攻击，并不该该被应用来处理。

例如，考虑一个搜索页面。当经过'%'参数请求时搜索服务器会返回全部的记录，这多是一个计算繁重的要求。要击垮这个网站，攻击者能够利用XSS漏洞将Javascript脚本注入某个公共论坛中，当用户访问这个论坛时，使用它的浏览器重复执行这个到服务器的搜索请求。或者即便不采用跨域请求，使用一个目标地址包含请求参数的图像元素也能够达到一样的目的。若是可能的话，攻击者甚至能够建立一个WebWorker执行这种攻击。这会消耗服务器大量的资源。

有效的解决办法是经过多种条件屏蔽掉非法的请求，例如HTTP头、参数等。

四、内部信息泄漏

假定一个内部站点开启了CORS，若是内部网络的用户访问了恶意网站，恶意网站能够经过COR（跨域请求）来获取到内部站点的内容。

五、针对用户的攻击

上面都是针对服务器的攻击，风险5则针对用户。比方说，攻击者已经肯定了你能够全域访问的productsearch.php页面上存在SQL注入漏洞。 攻击者并非直接从它们的系统数据库中获取数据，他们可能会编写一个JavaScript数据采集脚本，并在本身的网站或者存在XSS问题的网站上插入这段脚本。当受害者访问含有这种恶意JavaScript脚本的网站时，它的浏览器将执行针对“productsearch.php”的SQL注入攻击，采集全部的数据并发送给攻击者。检查服务器日志显示是受害人执行了攻击，由于除了来自Referrer的HTTP头通常没有其余日志记录。受害者并不能说他的系统被攻破，由于没有任何任何恶意软件或系统泄漏的痕迹。

3、攻击工具

Shell of the Future是一个反向WebShell处理器，它利用HTML5的跨站请求来劫持会话。

4、防护之道

一、不信任未经身份验证的跨域请求，应该首先验证Session ID或者Cookie。

二、对于请求方来讲验证接收的数据有效性，服务方仅暴露最少最必须的功能。

三、经过多种条件屏蔽掉非法的请求，例如HTTP头、参数等。

【编辑推荐】

1. 欧盟计算机安全局警告HTML5安全隐患

2. 专家称HTML5安全问题给企业带来新挑战

3. HTML5安全性：HTML5可否替代Flash 加强Web安全性