Click to Rate and Give Feedback
MSDN
MSDN Library
Web Development
HTML and CSS
 About Cross-Frame Scripting and Sec...
About Cross-Frame Scripting and Security

With Dynamic HTML (DHTML), content in different windows and frames can interact in powerful ways by scripting with the object model. However, since a browser can simultaneously display unrelated documents in its various windows and frames, certain rules must be enforced to protect data integrity and privacy of information.

This article describes how and why these restrictions apply in the DHTML Object Model. All rules about script interaction apply equally to windows, dialog boxes, frameSets, frames, and iframes.

For most content, only interactions with content from the same domain are allowed. For example, a typical page on www.microsoft.com can freely script content on any other page on www.microsoft.com, but cannot script to pages that are located on a different Web domain. The DHTML Object Model uses the document.domain property to enforce this restriction: only pages with identical domain properties are allowed free interaction. The protocol of the URL must also match. For instance, an HTTP page cannot access HTTPS content.

The range of permissible access for a page can be expanded when a script assigns the document.domain property to a suffix of the site name space, up to the second-level domain. For example, a page on www.microsoft.com can assign the document.domain property—initially www.microsoft.com—as microsoft.com to broaden access to include pages in home.microsoft.com or any other site, as long as the other pages also set the document.domain property to the identical value. Since only pages from a site whose name ends with microsoft.com will permit this domain to be set, it is assured that content from the same provider mutually agrees to interact and is free to do so. Domain suffixes shorter than the second-level domain (such as just "com") are not allowed, because they expose beyond a single provider. For international site names, such as www.microsoft.co.jp, the second-level domain for widest access would be "microsoft.co.jp" (not "co.jp").

Since it is important to be able to navigate windows or frames to any URL beyond the domain restriction, these types of accesses are always permitted. Only access that attempts to read out or modify content is restricted. For instance, the href property might be assigned to cause navigation to occur, but this property cannot be read if the URL is of a different domain. This would allow one page to learn where the user has been browsing, and to allow this is a breach of the user's privacy. Some restrictions that apply to pages of different domains include:

window.location.hrefProperty can be set to navigate, but cannot be read.
Other window.location.hrefFunctionality is blocked.
document.location.hrefProperty can be set to navigate, but cannot be read.
Other document.location.hrefFunctionality is blocked.
iframe.srcProperty can be set to navigate, but cannot be read.

Scripts that attempt to access parts of the object model to which they do not have access are blocked with a "permission denied" error.

While domain security can prevent certain types of content interaction, it is important to understand that this restriction is necessary to ensure security. For example, without domain security, a rogue page could "snoop" on another page or, using DHTML, manipulate its content.

Related Topics

Tags What's this?: Add a tag
Community Content   What is Community Content?
Add new content RSS  Annotations
跨frame的脚本和安全问题      Silent_Acorn   |   Edit   |  

Chinese Simplify:
在DHTML中,不同的窗口和框架(frames)中的内容可以通过对象模式用脚本相互交互。但是,由于可以在一个浏览器中通过多个窗口和框架同时显示多个毫不相干的内容,因此制定一定的限制性规则用于确保数据的真实性和保护个人隐私信息就显得很有必要的。
这片文章描述了为什么要添加这些限制性规则,以及这些规则在是如何应用在DHML模型上的。所有这些关于脚本交互的规则在windows, dialog boxes, frameSets, frames和iframes这些对象上都是一律适用的。
对于绝大多数内容而言,只有来至于同一个Web域的内容之间的相互交互操作才是允许的。例如,在www.studyez.com 上的一个页面可以用脚本自由的操作任何在www.studyez.com 这个站点的任何其他页面,但是不能通过脚本去操作在其他Web网站上的页面,即使这个页面通过iframe嵌入在www.studyez.com 的页面中。DHTML对象模型使用document.domain属性来判定这个限制规则:只有在同一个Web域里的页面才能自由交互。判断是否属于同一个Web域,要看域名主机、协议以及端口三者是否一致,只有三者完全相同,才能称之为同一个域。比如http://www.studyez.com/ 的页面与 https://www.studyez.com 的页面之间不能用脚本交互操作(因为协议不同),http://www.studyez.com 的页面与http://community.studyez.com 的页面之间也不能用脚本相互交互(因为域名主机不同),http://www.studyez.com:888/ 与 http://www.studyez.com/ 的页面之间一样也不能交互操作(因为端口不同)。
一个页面的脚本许可操作范围可以通过设置这个页面的document.domain属性而扩大到具有相同父域名的所有站点中。例如,在http://www.studyez.com/ 中的一个页面,通过脚本设置document.domain属性(初始默认是 www.studyez.com)为studyez.com,从而使得在http://gongwuyuan.studyez.com , http://community.studyez.com, 以及所有其他studyez.com所属的字域名中的页面都可以与这个页面进行交互操作,只要这些页面也相应的设置document.domain属性为studyez.com即可。由于只有那些来至于同一个父域studyez.com所属的站点的页面才可以设置document.domain=studyez.com,所以这也间接的保证了这些内容都是来自于同一个提供者并且双方都已经明确地作了允许互操作的设置。这个设置限制为父域名必须是有效的二级域名,对于.com, .net, 是如studyez.com,对于国际域名,如.cn,则是studyez.com.cn 或 studyez.cn,而不能是com.cn。
为了确保在windows和frames中可以加载任何网站的内容,所以导航操作是一直允许的,不受前面所述的规则限制。只有读取或者修改内容才是被限制的。如可以设置href属性以导航到新的页面,但是如果加载的页面不在同一个Web域里,则不能读取href属性,因为如果可以读取href属性的话,就可以知道用户正在浏览什么页面,而这是违反用户隐私策略的。对于处于不同Web域情况下,与导航相关属性的操作限制如下:

window.location.href 可以设置用于导航到新的页面,但是不可以读取
window.location除href之外的属性 禁止
document.location.href 可写不可读
document.location除href之外的属性 禁止
iframe.src 可写不可读

当脚本尝试受限的操作时,都会抛出一个"拒绝访问"的错误。
从安全的角度理解跨域脚本操作的限制是非常重要的,因为否则的话,一个恶意站点的页面可以通过嵌入iframe加载别的网站的内容从而通过脚本和DHTML模型为所欲为。

Tags What's this?: Add a tag
Flag as ContentBug
What about dynamically created iframes?      aspnetdev1427   |   Edit   |  

Question:

If a script on "www.microsoft.com" sets the page's document.domain to "microsoft.com", and then dynamically creates an iframe element and inserts it into the page's DOM, then new iframe becomes inaccessible to the script that created it. Assuming that the dynamically created iframe needs to be populated programmatically by the script that created it (as opposed to setting its "src" property and loading another page), how is it possible to do this? (Once the page's document.domain property has been set, all attempts to access the iframe's DOM result in an "access denied" exception.)

Any help would be greatly appreciated!

Tags What's this?: Add a tag
Flag as ContentBug
Processing
© 2008 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Page view tracker