Typically, the information available on web sites and servers is accessed using a web browser executing on a computer. For example, a user can launch a web browser and access a web site by entering a Uniform Resource Locator (URL) of the web site into an address bar of the web browser and pressing the enter key on a keyboard or clicking a button with a mouse. The URL typically includes three pieces of information that facilitate access: a protocol (set of rules and standards for the exchange of information in computer communication) string, a domain name (often based on the name of an organization that maintains the web site), and a path to the desired document within the domain.
Web browsers can render contents originated from different Internet domains. A major consideration of web security is the appropriate enforcement of the same-origin principle: although it has never been strictly defined, this principle can be loosely interpreted as “a script originated from one Internet domain should not be able to read, manipulate or infer the contents originated from another domain”, which is essentially the non-interference property in the web security context. Failures to enforce this principle result in severe security consequences, e.g., a script from an arbitrary web site can steal the user's banking information or perform unintended money transfers from the user's account. The malicious script can do almost anything that the victim user can do on the browser.
Same-origin-principle violations can be due to insufficient script-filtering of the web application on the server, or due to flaws in the browser domain-isolation mechanisms: 1) Script-filtering flaws are commonly referred to as cross-site scripting (or XSS) bugs. By exploiting these bugs, malicious scripts from attacker websites can survive the filtering and later be executed in the same security context of the authentic web application. A wealth of work in the security literature addresses prevention and defense techniques against XSS attacks. XSS is not the focus in this paper; 2) On the browser side, the same-origin-principle violations are due to the improper isolation of the contents from different domains, which is one of the biggest security problems faced by browser developers. Although at the policy-specification level, certain isolation policies still need to be standardized to support more browser functionalities while preserving security, it was found that even for a well-specified policy, the implementation of the enforcement mechanism can be surprisingly hard and error-prone. For example, the most well-known isolation policy is the cross-frame same-origin policy, which states that scripts running inside a frame of one address or site (say for example http://a.com) is not allowed to access objects inside a frame of another address or site (say for example http://b.com). Bugs in the enforcement mechanism of this seemingly simple policy have been discovered on major browsers, including Internet Explorer (IE), Firefox, Opera and Netscape Navigator.
In order to better understand the problem space, conducted was a focused study of IE's domain-isolation bugs and real attacks discovered in the past. The study shows that browser's flaws in the isolation mechanism are due to many convoluted factors, including the navigation mechanism, function aliasing, excessive expressiveness of navigation methods, the semantics of user events and IE's interactions with other system components. The exploitations of these flaws, which will be explained in detail below, are highly heterogeneous, and thus it would be very challenging to exhaustively reason about every scenario that the isolation mechanism may encounter. Of course, the unsolved challenge suggests that the browser may have new bugs of this type discovered in the future, similar to the situation that one can have with buffer overrun bugs—individual bug patches would not solve the problem as a whole.
The prevalence of browser isolation bugs in all major browser products naturally calls for a comprehensive defense technique. However, two practical constraints need to be considered when designing the defense technique: 1) the technique must be transparent to existing browser functionalities. A large volume of web applications have been developed based on existing browser functionalities. It would be a significant deployment hurdle if a defense mechanism broke these applications; 2) one may have only limited understanding of the browser implementation. Browser products have very large code bases. The comprehensiveness of the defense should only rely on the correct understanding of a small subset of the source code, and thus should be straightforward.