Summary: This paper is from 3 researchers at Microsoft. It addresses the problem of enforcing same-origin policy at web browsers. The same-origin policy basically means: a script from one "origin" should not be allowed to access (read/write/query existence) objects from a different "origin". An origin is usually determined by the host address + protocol + sometimes port number of the service. The philosophy behind it is rather simple: it is not safe to trust content loaded from any websites, semi-trusted scripts should be run within sandboxes, in which they are only allowed to access information from the same source (from - another Wiki reference :D) The authors pointed out that current implementations of web browsers are very complicated, which makes it very hard to guarantee correctness of the policy. They used Internet Explorer as their case study. IE uses frame-based isolation mechanism, putting each html document inside a frame represented by a window object, and provides window proxy objects for access from other frames. Reference to the original window object is kept secret inside its frame, cross-frame check is performed at the window proxy. Intra-access does not have to go through the check. The paper showed various attack scenarios, which were successful in executing a script from one domain in another domain's context. They either find a way to bypass the cross domain check, or presenting fake domain-ID to the checking module. Lets say the attacking frame is from http://evil and the target frame is from http://payroll a.. In the first scenario, the attacker took advantage of some local applications which can act as a proxy and forward script navigation request from evil frame to payroll frame. Because the request is received from a local application, old version of IE will service the request without cross-frame checking. (type 1) b.. In the second scenario, the attacker took advantage of alias ['eiliaes], setting a navigation function f of frame 2 equal to that of frame1, then load payroll into frame1 and have frame 2 executes f to navigate to a javascript. After the first step, frame 2 has reference to frame 1's function, which could be used directly. From the viewpoint of frame 2 this is a intra reference, and cross-frame checking is bypassed. (type 1) c.. In the third scenario, attacker took advantage of the confusing expression of a navigation call, which allow attacker to specify the function initiator. (type 2) d.. In the fourth scenario, the attacker took advantage of the ability to get direct reference of an object in a different frame using input capture functions. (type 1) To defense again such attacks, and possibly future attacks of the same type, the paper presented a mechanism called accent. Basically, each domain in the system will be given its own accent by the browser at run time. Each script will be encrypted by the accent of the domain which supplies its source [so:s] code, and each object name (by object they mean both functions and attributes)will be encrypted by the accent of the domain which hosts the object. This will ensure that the script can be decrypted correctly iff the receiving frame and the sending frame has the same accent, and an object can be accessed iff the requester and the requested frames have the same accent. They implemented a prototype of the mechanism in IE 6 and successfully prevented the 4 mentioned attack scenarios. It seems that the imposed overhead is negligible and the mechanism worked transparently with legacy applications. Overall I think this is a good paper. They implemented something useful without imposing huge additional overhead. I think the idea could be applied to other browsers as well.