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

一、从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等，主要是为开放平台向第三方提供 拜访的 威力  。

二、CORS带来的风险

CORS十分有用， 可以共享许多内容，不过这里存在风险  。由于它 彻底是一个盲 目标 协定，只不过通过HTTP头来操纵  。

它的风险包括：

1、HTTP头不得不 注明 申请来自一个特定的域，然而并不能 保障这个事实  。由于HTTP头 可以被伪造  。

所以未经身份验证的跨域 申请应该永远不会被信赖  。假如一些主要的 性能需求 袒露或者返回敏感信息，应该需求验证Session ID  。

2、第三方有可能被入侵

举一个场景，FriendFeed通过跨域 申请 拜访Twitter，FriendFeed 申请tweets、提交tweets而且执行一些消费者操作，Twitter提供响应  。两者都 彼此相信对方，所以FriendFeed并不验证猎取数据的有效性，Twitter也针对Twitter开放了大 部分的 性能  。

然而当假如Twitter被入侵后：

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

或者FriendFeed被入侵时：

Twitter响应FriendFeed的 申请，例如发表Tweets、改换消费者名甚至删除账户  。当FriendFeed被入侵后， 突击者 可以利用这些 申请来窜改消费者数据  。

所以关于 申请方来说验证 接纳的数据有效性和服务方仅 袒露 起码最必须的 性能是十分主要的  。

3、 歹意跨域 申请

即便页面只同意来自某个信赖网站的 申请，然而它也会收到大量来自 其余域的跨域 申请  。.这些 申请有时可能会被用于执行 利用层面的DDOS 突击，并不应该被 利用来 解决  。

例如，考量一个查找页面  。当通过%参数 申请时查找服务器会返回全部的记录，这可能是一个计算 沉重的要求  。要击垮这个网站， 突击者 可以利用XSS 漏洞将Javascript脚本注入某个公共论坛中，当消费者 拜访这个论坛时， 使用它的阅读器 反复执行这个到服务器的查找 申请  。或者 即便不采纳跨域 申请， 使用一个 指标地址包括 申请参数的图像元素也 可以达到同样的 目标  。假如可能的话， 突击者甚至 可以 缔造一个WebWorker执行这种 突击  。这会 消费服务器大量的资源  。

有效的解决 步骤是通过多种条件屏蔽掉非法的 申请，例如HTTP头、参数等  。

4、内部信息 透露

假如一个内部站点开启了CORS，假如内部网络的消费者 拜访了 歹意网站， 歹意网站 可以通过COR(跨域 申请)来猎取到内部站点的内容  。

5、针对消费者的 突击

上面都是针对服务器的 突击，风险5则针对消费者  。 譬如说， 突击者已经确定了你 可以全域 拜访的productsearch.php页面上存在SQL注入 漏洞  。 突击者并不是直接从它们的系统数据库中猎取数据，他们可能会编写一个JavaScript数据采集脚本，并在自己的网站或者存在XSS问题的网站上插入这段脚本  。当受害者 拜访含有这种 歹意JavaScript脚本的网站时，它的阅读器将执行针对“productsearch.php”的SQL注入 突击，采集全部的数据并发送给 突击者  。 审查服务器日志显示是受害人执行了 突击，由于除了来自Referrer的HTTP头普通没有 其余日志记录  。受害者并不能说他的系统被攻破，由于没有任何任何 歹意软件或系统 透露的痕迹  。

三、 突击工具

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

四、防备之道

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

2、关于 申请方来说验证 接纳的数据有效性，服务方仅 袒露 起码最必须的 性能  。

3、通过多种条件屏蔽掉非法的 申请，例如HTTP头、参数等  。