Su Yong Kim

Contents Domain Isolation Real-World Attacks Script Accenting Mechanism Attack Scenarios Revisited Performance Conclusion 2

Domain Isolation of IE Frame-based Isolation Scripts from one frame can access documents in another frame if and only if the two frames are from the same domain Same Origin Policy 3

Importance of Same Origin Policy 4 duam.net DaumWnd.document.submitForm.action =

Window Proxy Clone of the Window object String comparison is performed to check if the two domains are identical 5

Real-World Attacks Malicious frame Victim frame Purpose of attacks The script “doEvil” from is executed in the document from 6

Exploiting the Interactions between IE and Windows Explorer 7

Exploiting Function Aliasing 8

Exploiting the Excessive Expressiveness of Frame Navigation 9

Exploiting the Semantics of User Events The script from in Frame0 Creates frame1 to load Calls document.body.setCapture() to capture all mouse events When the user clicks inside Frame1 The event is handled by the method body.onClick() in Frame0 Event.srcElement in Frame0 can be used to access document object in Frame1 10

Exploiting the Semantics of User Events 11

Reason for Isolation Failure Unexpected execution scenarios to bypass the check Single-point check buried deep in the call stack  Challenging for developers to enumerate and test all these unexpected scenarios  Difficult to guarantee that the checks are performed exhaustively and correctly 12

Script Accenting Generate a 32-bit random number as the accent key for each domain of frame Before sending scripts or object name queries, XOR every 32-bit word in scripts and object name queries with the accent key of owner frame Does not increate the length of the script No possibility of buffer overflow After receiving scripts or object name queries XOR every 32-bit word in scripts and object name queries with the accent key of receiver frame 13

Accenting Script Source Code 14

Accenting Object Name Queries 15

Attack 1 Revisited Open(“file:javascript:doEvil”, “frame2”) InvokeNavigation does not accent “file:javascript:doEvil” because it is not javascript-URL Windows Explorer removes the “file:” and passes “javascript:doEvil” to frame2 Compile de-accents “javascript:doEvil”  ATTACK Fails! 16

Attack 2 Revisited Location.assign(‘javascript:doEvil’) InvokeNavigation accents “javascript:doEvil” with the key of Compile de-accents (javascript:doEvil) k with the key of  ATTACK Fails! 17

Attack 3 Revisited Frame2.open(“javascript:doEvil”, “frame1”) InvokeNavigation accents “javascript:doEvil” with the key of Because script source code resides in Compile de-accents (javascript:doEvil) k with the key of  ATTACK Fails! 18

Attack 4 Revisited Event.srcElement InvokeByName accents object name queries with the key of GetDispatchID de-accents (object name queries) k with the key of  ATTACK Fails! 19

XOR Probing Attacks Guessing (k atk k vtm ) Attack String doEvil (k atk k vtm ) Probability 1/(256) 4 Verification No way to detect syntax error of victim’s frame 20

Performance Worst Case 3.16 % overhead 21

Conclusion Analysis of IE’s domain-isolation mechanism and the known attacks Proposal of the script accenting technique Extension to non-browser platform Application Domain of CLR(Common Language Runtime) in.NET framework Limitation IE-dependent implementation 22

Discussion Thanks for Listening! 23