Same Origin Method Execution

Author: @BenHayak

About the Attack

Same Origin Method Execution (SOME) is a web application attack that allows hijacking the execution of Web-Application "Document-Object-Module" and/or scripting methods on behalf of users.

In the SOME attack, the victim initially visits a malicious link or is lured by a malicious advertisement. Subsequently, an unlimited predefined set of actions is executed by the victim's user agent (as in an XSS attack). By abusing the victim's session, SOME can perform actions exactly as if the victim has triggered them on his or her own. Unlike many other similar attacks, SOME neither requires tricking the user into clicking on hidden objects, nor is confined in terms of user interaction, browser brand, frame busting, HTTP X-FRAME-OPTIONS/Other response headers or a particular web-page. In fact, when a web-page is found vulnerable to SOME, the entire domain becomes exposed to its resulting vulnerabilities.

Logo

Paper, Demo and Slides from Blackhat:

If you wish to invest your time in exploring the fascinating technical details in-depth, you are encourage to read my white-paper (mirror), or look at the updated Black-Hat presentation. The slides include a demonstration video of a SOME exploit - you can see how I used SOME to hijack Google cloud's private photo and video albums.

Useful Resources

How Do I Protect myself?

In order to protect a web application from Same Origin Method Execution one should replace arbitrary callback execution with one of the following approaches:
  • Static Callbacks - Exploiting Same Origin Method Execution relies on abusing a callback parameter. Many web applications can actually maintain their same existing functionality without having to dynamically set callbacks. Thus, when applicable, websites should use fixed callback values as opposed to externalizing the callback control.

  • White-list approach – In cases where the web application is designed for supporting more than a single callback per endpoint, or, alternatively, where maintaining a high flexibility is highly important (common in Flash plugins), it is better to set a white-list and match the given callback parameter value against it. This would enforce and verify that only legitimate callback functions can execute.UPDATE: I am working on a JavaScript defense library aiming to serve as a generic and easy to deploy solution.

  • Cross-Domain Messaging – Use postMessage for notifying events and interacting to and from cross-domains as an alternative to javascript callback execution (if applicable).