标签归档:web

WEB安全_浏览器安全_sandbox

  浏览器SandBox

google chrome 是一个采取多进程架构的浏览器,主要进程分为:浏览器内核进程,渲染引擎进程,插件进程,扩展进程等。这里针对google 开源chromuim进行说明。

Chromium允许渲染进程运行在Sandbox里,这样即便代码存在漏洞被网页利用了,也不会对系统造成威胁。

关于sandbox的安全机制,伯克利和斯坦福大学的研究学者们做了一个很好的论文,下面就泛泛的结合他们的论文谈一下。他们的论文题目为:《The Security Architecture of the Chromium Browser

》。

chromium 拥有2个模块来保护域安全,

browser kernel:其是和操作系统交互的。

rendering engine 渲染引擎,在沙箱中运行,限制权限。

1 简介

浏览器内核模块的行为代表用户,而渲染引擎模块代表网页,模块运行在单独的保护域,通过执行沙箱,降低了渲染引擎的权限。即使攻击者利用未修补漏洞的渲染引擎,获得整个渲染引擎沙箱的特权,也可以防止攻击者读写用户的文件系统

浏览器的安全策略,像同源策略一样复杂,可以说这种细粒度的隔离难以不破坏现有的网站,用户又要求其兼容性,为了兼容,一个模块化的浏览器必须要支持整个网络的平台。

浏览器的内核是负责管理持久性的资源,如cookie ,password database;以及用户和操作系统交换,接收用户的输入,并绘制到屏幕上,这个架构是基于以下2点的设计:

1)   该体系架构必须要兼容现有网络,具体而言,安全性限制网站的结构应该是透明的,这样的设计决策,极大的限制了整个体系结构的范畴。

2)    该体系结构将渲染引擎作为黑箱,将未解析的HTML作为输入,并将产生位图输出,尤其是该体系架构依赖于渲染引擎来执行同源策略,这样的设计降低了浏览器内核安全监控的复杂性,因为浏览器内核只需要执行粗粒度的安全增强便可以,例如,浏览器内核赋予对上传整个实例到渲染引擎的能力,这种特权值只需要单个的安全 “源”,

这种架构不能防止攻击者妥协渲染引擎从而攻击其他站点,(如读取其cookie);相反,该结构体的目的是房子读写用户的文件系统,从而帮助用户避免恶意软件侵袭。

为了评估chromium的安全性,我们选取离开IE,Firefox,Safari的漏洞统计,来确定那些漏洞会影响到chromium,发现其中67%的会发生在渲染引擎的地方。

chromium的体系结构为了减轻严重漏洞的危险,重新严格限定了攻击者使用浏览器内核的接口。测试了代码执行的漏洞会发生在浏览器内核中,其中72.7%的漏洞会利用充分验证的系统调用,而不是减轻了附加的沙箱。如,利用一个不当转义的Shell Execute弱点去攻击浏览器的外部协议。虽然这些弱点的统计不是很完善,但这些结果,让我们相信chromium的体系结构,适当的划分l浏览器内核和渲染引擎的浏览器组件。

     将浏览器分为2个保护区域,一个表示用户而另一个则是网页,chromium的安全体系架构可以减轻月70%的浏览器关键漏洞和攻击者执行的代码,其余的漏洞则归为沙箱来处理,这样架构可以充分利用沙箱的安全优势,又能够保持性能和现有的web的兼容性。

     首先采取的是三管齐下的措施来考量其兼容性,首先是通过完成99%的10115次兼容webkit的测试,第二人工访问了500个最为流行的网站来发现其不兼容性,第三通过已经部署的上以百万的用户反馈。

2威胁模型

为了表示chromium的安全属性,我们定一个枚举攻击者的能力和目标威胁模型,这个安全体系结构旨在防止攻击者为了达到目标所拥有的能力,我们可以利用这个威胁模型来评价chromium的架构如何有效的保护用户免受攻击。

(一)hacker的能力:我们认为攻击者知道一个未打补丁的安全漏洞在用户的浏览器上,并能够利用用户的浏览器渲染恶意的内容,通常,这些能力足够威胁用户的及其,更为具体的说,我们假设攻击者具备以下能力:

1)   攻击者拥有一个域名,如attacker.com 。这个域名还未添加到浏览器的恶意软件的黑名单中,攻击者拥有一个有效的https的证书域,并在网络上控制至少一台主机。具备这些能力只需5美元

2)   攻击者可以说服用户访问他的网站,这是很难的价格来衡量这种能力,但在以前的研究中,能吸引一季度100万用户只需要50美元左右

3)   攻击者利用利用一些exploit,攻击一些未打补丁的可以执行任意代码漏洞的用户浏览器,如HTML解析器的缓冲区溢出,正则表达式库的证书溢出,或书签的缓冲区溢出。

(二)范围内目标,chromium架构侧重于防止攻击者从三个高度实现目标:

1)   持续的恶意软件,攻击者试图在用户计算机上安装恶意软件,如:安装一个僵尸网络的客户端,接收命令,在网络中工作或协同其他用户参与网络工作。

2)   键盘记录器,攻击者监视用户的击键,用来盗取用户密码和隐私数据。需要在用户没有关闭浏览器才能生存。

3)   文件盗取,攻击者企图获取用户磁盘上的敏感数据

如果攻击者能够实现这些目标的一个或多个,将会给用户造成严重的危害,chromium的体系架构目的是防止攻击者的这种能力

三) 范围外的目标,有很多攻击者的目标是chromium体系机构不提供的额外保护,chromium包含一定的特性低于这些危险,这些特性依赖渲染引擎执行的”同源策略”

1)   网络钓鱼,在钓鱼攻击中,攻击者使用一些技巧让用户进入一个不城市的网站,并提供了自己的密码。攻击者利用未修补的漏洞可以创建一个说服钓鱼网站破坏一个窗口显示真实的网站。

1)chromium具备多项安全功能减轻网络钓鱼攻击,浏览器突出显示网站域名,已知钓鱼网站的安全警告,以及额外的安全性用户界面元素。

2)   “源隔离” chromium的架构 渲染引擎将会对整个网络站点为主进行渲染,意味这渲染引擎可以代表整个网站,例如,攻击者利用代码执行漏洞获得cookie,存储在浏览器内密码,如果攻击者不能利用这些未修补的漏洞,通常浏览器的安全策略防止攻击者读取coolie或密码,主机名不在他的控制下。

3)   防火墙规避,同源策略是限制攻击者的访问是在浏览器内,防火墙规避旨在保护机密资源。

4)    网站的漏洞,如果网站包含xss,csrf,以及header注入等,这些需要网站必须修复其脆弱性。 chromium支持httpOnlyCookies来缓解部分XSS

3 chromium架构

 

chromium结构有2个模块,渲染引擎和浏览器内核,在一个较高的水平,渲染引擎负责转换HTTP响应和用户输入事件转换为呈现的位图,而浏览器内核则负责用户操作系统进行交互,内核的浏览器公开API,渲染引擎使用网络发出请求,访问持久化存储,并显示在用户的屏幕上的位图。浏览器内核是值得用户信任的,而渲染引擎则是值得网页信任的。

(一) 渲染引擎,渲染引擎解释执行网页内容提供的默认行为,如绘制<input>元素,和服务调用DOM API,呈现的网页进行了几个阶段,1 开始与解析,建立一个在内存的DOM表示,奠定了图形化的文件和操作文件,解析脚本指令,渲染引擎也负责限制同源策略,着有助于防止恶意网站中断用户和真实的网站会话。

                                                              (表1)

      渲染引擎         

      浏览器内核

      HTML 解析     

  cookie数据库

      CSS 解析        

      历史访问数据库

      图像解码         

      密码数据库

      js解释器         

      窗口管理

      正则表达式      

      地址栏

      布局               

      安全浏览黑名单

      文档对象模型   

      网络协议栈

      渲染             

      SSL/TLS

      SVG               

   磁盘缓存

      XML解析        

      下载管理

      XSLT              

      剪贴板

BOTH

URL 解析

unicode解析

(一)渲染引擎,包含拉大部分浏览器的复杂性和佳和最直接的与不可信网页内容,例如大多数的解析发生在渲染引擎,包括HTML解析,图像解码,js解析。为了与用户,本地主机,网络交互,渲染引擎使用了浏览器内核的API,渲染引擎运行在操作系统限制的沙箱中。

(二)浏览器内核,浏览器内核负责管理多个实例的渲染引擎和实施的浏览器内核API,例如,浏览器内核实现了基于选项卡的窗口系统,包括地址栏,显示当前处于获得的URL选项卡,及其相关的安全指标,浏览器内核管理的持久化状态,如用户的书签,cookie,并保存密码,它还负责与网络进行交互与渲染引擎与操作系统的原生窗口管理器之间的中介,为了实现它的API,浏览器内核维护状态信息的权限,并据此向每个渲染引擎,如允许上载文件的列表的每个渲染引擎,浏览器内核使用这些安全策略防止渲染引擎被攻破后与用户操作系统的隔离。

驱动的浏览器组建分配的任务还有一些是为了兼容性遗留的,比如浏览器内核负责js alert警告,select下拉菜单则有渲染引擎, 某些功能,如cookie数据库还是有浏览器内核实现的,因为它直接访问文件系统,正则表达式则有渲染引擎来实现,因为他对性能是敏感的,而且有常见的安全漏洞。

正如表1所示,渲染引擎负责对于大多数的分析和加密,因为历史上,这些任务已经发生大量的源漏洞,例如,要显示一个网站的快捷图标,在浏览器用户界面,浏览器内核网络检索图像,但并不实体进行解码,相反,浏览器内核发送图像用于解码的渲染引擎,渲染引擎响应一个未压缩的图标的位图,其中浏览器内核将其复制到屏幕上,这个看似复杂的步骤,有助于防止攻击者利用一个未修补的图像解码器漏洞控制浏览器内核。这种模式的一个例外是网络协议栈,HTTP协议栈是负责解析HTTP响应头和调用gzip或bzip2解码器解压缩,这些内容编码HTTP响应,这些任务分配给渲染引擎,在成本上复杂的网络堆栈和降低性能。而URL需要浏览器内核和渲染引擎都去解析,因为URL处理无处不在。

(三)进程粒度:粗略的说,chromium使用一个单独的实例为每个标签开启一个渲染引擎,显示的内容从网页,在渲染引擎崩溃的情况下提供容错。使用渲染引擎提供受信证书的解析,如HTTPS 证书错误的警告,然而,这些渲染任务是有一个单独实例的渲染引擎,不处理从网络上获得的内容。主要的里外这种模式是web检测器,他显示信任呈现的内容和有渲染引擎显示的网页,chromium采用这种设计,因为WEB检测器交互广泛的页面检查。

插件 – chromium的架构中,每个插件运行在一个单独的主机进程中,单独于渲染引擎和浏览器内核,为了兼容现有网站,浏览器插件无法在渲染引擎里运行,因为供应商期望插件最多有一个实例的插件在web 浏览器。如果插件驻留在浏览器内核,插件的崩溃,就足够崩溃了整个浏览器。在默认的情况下,每个插件运行在沙箱以外,而且用户具有完全访问的权限,这个设置将保持现有的插件和网站,因为插件可以有任意行为,如flash 播放器插件可以控制用户的microphone和webcam,以及用户的文件系统,此设置的限制是,攻击者可以利用未修补的插件漏洞在用户计算机上安装恶意软件,供应商可以写入chromium的sandbox,能为用户提供更到范围的防外挂攻击,chromium还有一个选项,以现有的插件在sandbox中运行,要做到这一点,chromium提供一些安全设置,–safe-plugins 在命令行中设置。此设置只是实验性的,可能导致不稳定或以外现象

4沙箱

 

为了帮助抵御攻击者利用一个chromium渲染引擎的弱点,每个渲染引擎都在sandbox中,sandbox限制了渲染引擎的在运行过程中的系统调用,这些系统调用可以帮助用户达到目标。

(一)目标: 在理想状态下,sandbox会迫使渲染引擎使用浏览器内核的API与外界进行交互,许多DOM方法,如appendChild方法。在渲染引擎中实现简单的状态改变以及完全改变,在DOM方法中,XMLHttpRequest方法需要渲染引擎做的不仅仅是内部状态,一个可信的渲染引擎可以使用浏览器内核的接口来实现这些方法,sandbox目标是需要一个妥协的渲染引擎来使用浏览器内核与用户和文件系统交互。

(二)实现:当前,chromium的特定功能-sandbox渲染引擎,为了替代基于windows安全口令的方法,渲染引擎使用了Restricted Token的安全令牌的方法。每当渲染引擎试图访问一个安全对象时,Windows安全管理器会检查渲染引擎的安全令牌是否有足够的权限访问该对象。sandbox这种严格限定渲染引擎安全引擎的安全检测方法几乎在每一次这样的访问中。

(三)在渲染web协议栈。渲染引擎调整其进程的安全令牌,将安全标示符SID设置为DENY_ONLY,并添加一些严格的SID和调用AdjustTokenPrivileges函数。渲染引擎一样可以运行在一个单独的桌面中,以用来减轻安全性检查不严的WINdows API。如 调用 SetWindowsHookEx,限制一些有用无安全问题的对象,如 HWND_BROADCAST,这些目前仅限于桌面。此外,渲染引擎在windows作业对象上,限制了渲染引擎创建进程,读写剪贴板,访问用户处理的能力。

四) 限制: 虽然sandbox 限制和妥协渲染引擎交互操作的一些能力,但sandbox本身还有一些限制

1)   FAT32: fat32不支持访问控制列表,没有访问控制列表,windows的安全管理器会忽略进行的安全令牌。

2)   错误的配置对象:如果一个对象有一个NULL DACL(Discretionary access control list),在windows 安全管理器将授予访问权限,而不考虑访问的安全性令牌,虽然NULL DACL是涵见的,但一些第三方应用程序会创建NULL DACL对象,在NTFS文件系统中,问题大大减少,因为这种限制在沙箱中的删除权限,“跳过安全遍历”,迫使windows渲染引擎能够访问到目标文件的父目录。

3)TCP/IP 理论上讲,渲染引擎在Windows XP创建一个SOCKET 套接字,因为低级别的系统调用打开一个套接字,不需要操作系统执行访问检查,然而,通常win 32为库函数在创建套接字时失败,因为这些API是渲染引擎无法捕获的。我们试图建立一个POC(Proof-of-concept),在sandbox中进程无法打开套接字。在Vista中,有关的系统调用会执行安全访问检测,

 5 浏览器内核接口

 

sandbox渲染引擎限制直接与底层操作系统交互的能力。如用户交互持续性存储和网络,渲染引擎依赖与浏览器内核的API,在提供函数给渲染浏览器功能时,一定要仔细设计不授予没有必要的权限,特别是浏览器内核不能设计成泄漏读写用户文件系统的能力。

(一)用户交互: 操作系统交互的接口,允许应用程序与用户进行交互,但这些接口没有设计要使用不受信任的程序,如 X windows 系统,以创建一个窗口的 X server,意味着监视所以用户的击键,浏览器内核是渲染引擎的中介,以协助执行2个安全约束与用户互动。

1)   渲染。不是给与渲染引擎直接访问一个窗口的句柄,渲染引擎引入一个离屏位图。要显示位图给用户,渲染引擎发送的位图给浏览器内核,浏览器内核复制位图到屏幕上。这种设计增加拉一个单独的屏幕,如一般的绘图到屏幕是通过内存拷贝到内存管道,其中有一个类似的双缓冲性能的影响,以及所呈现的位图浏览器窗口的内存区域。

2)   用户输入,而不是传送用户输入直接到渲染引擎,操作系统提供这事件给浏览器内核,浏览器内核调度这些事件定位当前用户界面元素。如果焦点在chrome浏览器上,输入事件则有浏览器内核处理,如果该内容具有焦点时,浏览器内核将输入时间交个渲染引擎,本设计利用用户的焦点来限制用户的输入事件给渲染引擎。

(二)持久性存储:sandbox的责任是确保渲染引擎的责任是不能直接访问用户的文件系统。然而,渲染引擎不需要一些用户的文件上传和下载

1)   上传,用户可以将文件上传到网站,需要上传控制,当用户点击表单控件,浏览器显示一个文件选择的对话框,让用户选择上传的文件,如果浏览器内核不限制文件,渲染引擎可以直接上传,攻击者利用渲染引擎便会读取用户文件系统的文件

chromium采用了类似DarpaBrowser的powerbox模式,处理用户的选择,授权到同一个文件选择对话框的文件上传文件到任意网站,浏览器内核负责显示文件对话框和记录文件的用户已授权渲染引擎的历史,同样当文件拖放到浏览器的内容,渲染引擎积极渲染上传的授权文件。

2)   下载,当下载文件时,一个网站允许写入到用户的文件系统,不是直接的写入文件系统,而渲染引擎使用浏览器内核的API下载,为了保护文件系统,浏览器内核下载到指定的下载目录,此外浏览器内核黑名单的某些文件名,渲染引擎可以用它来提升权限检测,如设备名,文件名,本地扩展,shell集成的文件名,如:desktop.ini

(三) 网络 而不是直接访问,渲染引擎检索通过浏览器内核从网络中检索URL,在一个URL请求提供服务,渲染引擎检查浏览器内核是否授权的URL,网络的URL协议如http,https,FTP,可以请求每个实例的渲染引擎。浏览器内核防止大多数渲染引擎请求URL的方案,因为一个有漏洞的渲染引擎可以读取用户磁盘驱动器的各种文件的URL。

6 chromuim 源代码下载

 

获得chromuim源代码的方法如下:

           1 安装gclient工具:

获得 depot_tools:git:

添加depot_tools 路径 PATH:$ export PATH=”$PATH”:pwd/depot_tools

也可以添加到. bashrc 文件中。

2) 下载代码

7 chromuim 源代码举例

以上是POC的一段代码,由于分析代码不是本文的主题,这里就不深究下去了,此章只是想让大家了解浏览器安全的问题。
除了上面的安全问题,还有恶意网址拦截等安全问题,这里就不再分析下去了

WEB安全_浏览器安全_同源策略

1 概述

本文是走入Linux操作系统系列的其中一篇,本文主要是针对近期关于web安全检测的一些学习和体会,web安全的关心范畴来自于web开发人员,测试人员,安全运维人员,以及互联网的另一头所谓的小黑们。WEB的应用逐渐成为互联网的核心,WEB的安全技术也在兴起,对web安全的问题爆发也越来越流行。
2011年末,一场有CSDN密码泄漏用户数据的事件掀起了一场血淋淋的个人密码泄漏大幕。跟随着网x,xx网,天x,猫x等大型网站的爆库现象,用户的用户名和密码便在互联网上随意下载,一时风声鹤唳,草木皆兵。

2 前言

2011年的那场爆库现象,警方也得出结论,模糊的记得其中2条(与本文不太相关,没有深究其准确性),一是安全意识不够,管理不规范。二是没有使用国家规定安全级别的操作系统。安全问题大都是出自对安全意识问题,如:你的密码在各大网站注册的时候,无论是用户名和密码都是一样的,甚至是你的邮箱。邮箱问题很是严重,因为很多网站是通过邮箱找回密码的,邮箱破解了,很多你的个人秘密和利益都被破解了,当然这其中有一部分属于社会工程学范畴。

一篇文章不能把web安全相关的东西讲的很全面,但我想还是将一些比较重要的东西说出来比较好,这样可以丰富大家的知识。写一篇文章要参考了很多书籍和资料,这里推荐大家的资料为:《The.Web.Application.Hacker’s.Handbook.Finding.and.Exploiting.Security.Flaws,.Stuttard,.Pinto,.2ed,.Wiley,.2011》,当然这本中文翻译本也有了,《黑客攻防技术宝典:Web实战篇(第2版)》 china-pub 地址为:http://product.china-pub.com/3662840 。《白帽子讲WEB安全》。

 3WEB安全发展历程

 

说起安全就会想起hacker这个词,hacker这个词的褒贬暂且不提,对于hacker来说,不想拿到root的hacker不算好hacker,在hacker的行业里,有人分为2种黑客,一种是玩exploit(精通计算机技术,挖掘漏洞编写exploit),另一种是玩脚本的(对攻击本身感兴趣,编程技术不是很高)。在国内存在者一些功利性比较强的黑客,与本主题无关这里闭而不谈。

黑客帝国想必大家都看过吧,其中有很多镜头,如下图:

其中这张图利用到了常见的nmap和ssh,以及一个sshnuke的exploit。最近韩国的幽灵电视剧也有很多镜头显示黑客们利用exploit的技能。但现在的电视剧上关于黑客的镜头大多是无厘头的,cd,ls什么的,便可以入侵了。有点玄乎。

Web安全问题的兴起在web1.0时代,关注服务器动态脚本的安全问题,如webshell(将可执行脚本上传到服务器)。

SQL注入以及XSS的威力也逐步被大家重视,在web2.0时代,XSS以及CSRF的危险则更强大。

上图是2007-2011年web应用安全事件的统计表。

要全面的认识一个安全问题,首先要明白安全问题组成的属性,有人提出了安全的三个要素:机密性,完整性以及可用性,后来有人补充了可审计性和不可抵赖性等要素。

设计安全方案,要做到以下几点:

     1 能够有效的解决问题

     2 用户体验好

     3 高性能

     4 低耦合

     5 易于扩展和升级

安全问题的发展历程也不是短短百十字能描写清楚,HTML5以及云计算的爆发,对web安全要求越来越高,下面从理论性上简单的了解一下web安全的问题。

 4 脚本安全

4.1 浏览器安全

浏览器是互联网的最大入口,每个浏览器都有自己的安全特性,而同源政策的一种安全约定是浏览器最为核心也最为基本的安全功能。web是建在同源策略的基础之上,浏览器则是同源策略的一种实现。

4.1.1同源策略

什么是同源策略?

同源策略是指浏览器会阻止从一个域上加载的脚本获取或者操作另一个域上的文档属性,也就是说,受到请求的URL的域必须与当前的WEB页面的域相同,否则浏览器会主动隔离来自不同源的内容。这一种同源策略,限制了不同源的”document”或脚本。

同源是指:同协议,同域名,同端口,host(域名或IP地址,如果是IP地址可以当作子域名)

他的精髓很简单,它认为任何站点装载的信赖内容是不安全的,当被浏览器半信半疑的脚本运行在沙箱时,它们应该之被运行访问来自同一站点的资源,而不是那些来在其它站点可能怀有恶意的资源。

需要注意的是,对于当前页面来说,页面内存放的javascript文件的域并不重要,重要的是加载js的页面所在的域是什么。如

a.com通过以下代码加载b.com上的b.js。但js是运行在a.com页面中。

a.com的index页面调用b.com的b.js。b.com的index也同样调用b.js.该测试按钮的作用显示当前的href页面。

<script type=”text/javascript” src=”http://www.b.com/b.js”></script>,其测试效果如下:

这个是a.com的测试效果,显示为www.a.com。

而这个则是b.com的测试效果,显示的为www.b.com。

测试的效果显示,其中b.js的脚本是在a.com的页面中运行。因此对于当前页面a.com来说,b.js的源则是a.com;而不是b.com;

测试代码如下:

b.js内容:

同样的对于<script>,<img>,<iframe>,<link>等标签都可以跨站加载资源,而不受同源策略的限制,实际上这些带”src”属性的标签每次加载时,是由浏览器发起一次GET请求。不同与XMLHttpRequest的是,通过src属性加载的资源,浏览器限制了javascript的权限,使其不能读写返回的内容。

点击测试按钮

而在站a.com则会出现,其中返回错误状态码为0。B1.txt没有取到

可以看的出,XMLHttpRequest 受到同源策略的约束,不能跨域访问资源。

测试代码如下:

b.js loadXMLDoc;

xmlHttptest.html code: b.com的代码。a.com域的代码类同。

但,随着互联网的发展,跨域请求的需求越来越多,W3C委员会制定了针对XMLHttpRequest跨域访问标准。他需要通过目标域返回的HTTP头来授权是否允许跨站访问,由于HTTP对与js来说一般是无法控制的,所以认为这个方案是可以实施的,但注意,可以跨域的方案的安全基数是信任”Javascript无法控制该HTTP头”。如果此信任被打破,则方案也将不在安全。

以下将在chrome上实现跨域访问的实验

点击测试按钮,结果如下:

这个测试需要在服务器端进行修改http header,使其支持Access-Control-Allow-Origin协议。

我们可以抓取http报头信息看到:

http://www.b.com/test.php?url=http://www.b.com/b1.txt

 

———————————————————

下面将贴出测试代码:

需要修改b.js的loadXMLDoc(url)函数体的地方

需要使用php修改header的代码

如果使用的其他语言实现,需要使用request.addheader方法实现,IE8需要使用XDomainRequest的方法。

跨域的风险是要注意的,ajax一般不允许跨域,也要根据不同的浏览器设定了。跨域容易引起第三方的恶意安全注入,网络攻击者(“中间人攻击”) 可能篡改服务器响应内容从而可能攻击你编写的扩展内容。

对于浏览器而言,除了DOM,Coookie,XMLHttpRequest受到同源策略的限制外,第三方插件也有各自的同源策略。如 flash,JAVA Applet等。

同源策略也会有很多漏洞,这里就不再深究下去了,有兴趣的可以查阅互联网