Introducing Checkmarx Software Composition Analysis (CxSCA)

Beyond XSS and CSRF: Same Origin Method Execution

Unless you were living under a rock last fall, you heard about the major iCloud hack that saw nude pictures of A-list celebrities posted all over the web. The fact that someone could hack into private clouds and steal the sensitive data contained within alarmed web users around the world.


That wasn’t the only exploit of its kind. If someone malicious had discovered another, similar exploit on Google+, there could have been a similar batch of stolen photos.


Luckily, the hacker that found them is a white-hat and plays for the good side. Ben Hayak plays for the good side, and our private Google Plus photos have been saved from prying hands.


Ben, a senior security engineer at Salesforce, recently discovered a method of attack that would pose major threats to users and sites with successful attacks.


Same Origin Method Execution


While doing research on a few web apps on his own, Ben noticed that some apps used multiple windows and frames to interact with each other. “By breaking the expected flow,” Ben says, “the interaction would cause an error.” He didn’t think much more about it – until he saw the same issue on Google with an OAuth pop-up window. That’s when he realized this was potentially something big.


Breaking Down Same Origin Method Execution Vulnerability


The Same Origin Method Execution attack, known better as SOME, is a web app attack abusing the concept of callback endpoints by “forcing a victim into executing arbitrary scripting methods of any page on the endpoint’s domain,” as Ben explains. In short, SOME attacks forge a setup of windows or frames in order to redirect users to documents in a way that will yield the execution of malicious web functionality. The effects are different depending on which application is attacked. For example, after Ben presented his findings, another white-hat, Jakub Zoczek, discovered that Microsoft’s private social network Yammer was vulnerable to attack.


The attack flow goes like this:


  1. The victim visits a malicious link
  2. The link causes the user’s browser to open new windows or frames containing malicious code
  3. The application then allows the vulnerable callback URL to render the document targeted by the attack, and can be done quickly so the victim has no idea what happened
  4. The application is ‘tricked’ into thinking both sites are trustworthy, and the application can now be hijacked into thinking all actions are being done by the end user


For a deeper look at the Same Origin Method Execution attack, check out Ben’s research paper.


The Google Plus Same Origin Method Execution Attack


One of the more serious instances of the SOME vulnerability being exploited was with Google Plus, Ben discovered. When using Google photos, you have the option to auto-backup your pictures to your private collection. Google also hosts a service called Google Picker, which allows users to share their media with third-party sites. And using Google Picker, Ben had the ability to steal someone’s private photos.


Here’s what the attack looks like:


Same Origin Policy & JSONP


Because the SOME attack exists because of weaknesses within websites using Same Origin Policy, let’s quickly go over the security policy. The need for Same Origin Policy arises out of the need to separate the content provided by sites unrelated to each other; Failure to do so can lead to one site leaking confidential information to the other, as we will see in this attack.


Same Origin Policy, or SOP,  was designed to prevent scripts loaded from one domain from manipulating or stealing document properties from another domain.


originThe mechanism, enforced by your browser, will only give permission to a script on one domain – for example, when you’re logged into your bank account – to access data on a second domain if the two web pages have the same origin. Origin relates to the combination of the URL scheme, hostname, and port, as you can see to the right. The goal of SOP, in other words, is to prevent having your details leaked to sites not directly involved with the application you’re using.


But there are situations where an application needs to overcome SOP, such as when you’re authorizing a site through OAuth. One of the methods of JavaScript Object Notation with Padding – JSONP – is what “opened the backdoor for the SOME attack,” Ben says in his talk at last year’s Black Hat Europe. Developers use JSONP to overcome SOP, allowing different domains to communicate with each other. And it’s in these instances where SOME has the best chance of popping up.


If JSONP isn’t correctly used, the callback parameter (like OAuth) can be manipulated, making the execution of arbitrary scripting methods possible on the vulnerable site.


Go Deeper: Watch our talk on the Security Storms Brewing in Your JavaScript

What Happens to SOME Victims


Since attacks are bound by the capabilities exposed by the targeted vulnerable web app, the effects differ from application to application. In general, however, end results of the attack include “clicks, form submissions, form input value tampering, JavaScript functions and similar,” Ben writes in his research paper.


Like XSS attacks, SOME attacks affect only the end user, but if the end user happens to be a sysadmin or similar, the effects of a SOME attack can be detrimental for the site, giving the attacker access to compromise the app in its entirety.


But, unlike XSS or CSRF attacks, SOME attacks are “more about manipulating the surface rather than using a special payload or abusing a specific vulnerable web action,” Ben says. On top of that, because the SOME exploit hijacks sessions use client side method execution to serve their attack, even a CSRF token wouldn’t protect the end user from the attack.


How Your Site Can Be Affected


“Many web application developers use ‘Same Origin’ pop-ups/frames to interact and execute fixed and/or dynamic callback methods”, Ben says. “The key [to the SOME attack] is to manipulate the expected ‘Same Origin’ flow and, therefore, use their own code against them.”


In his paper, Ben lists these four reasons as to the reasons why an application could be vulnerable to this attack:


  1. If the application requires “secure delegated access” to third party server resources like OAuth
  2. If the application opens a pop up window so as not to lose the current content being displayed
  3. If the application developers use a simpler yet unsecure SOP bypass
  4. If developers simply lack security awareness


These interactions with third party services, especially OAuth dialogs which allow users to sign in using login data used for other web apps, are prime for attack using Same Origin Method Execution. The really troubling aspect of the SOME attack is that if one domain is vulnerable, all pages within the same site are also vulnerable.


Go Deeper: Read about how another hacker discovered major Android security flaws because of website weaknesses revolving around Same Origin Policy 


How to Avoid SOME Vulnerabilities In Your Web Apps


To avoid SOME attacks in your own web applications, Ben suggests developers to avoid using “any user data within the execution of callbacks or the interaction with a different window [or other] browsing contexts.”


The three best defenses, for now, against SOME attacks for websites that use JSONP are:


  1. Use a static function name for all callback endpoints
  2. Whitelist callbacks on the server side
  3. Register callbacks


To go along with the third method of mitigating vulnerable SOME instances,  Ben is working on something that will be available in the near future. In the last few months, Ben has begun work on SOMEguard, a client-side whitelisting solution, developed in JavaScript, to guarantee protection against SOME – while still allowing dynamic callbacks like OAuth. When it’s released – he’s shooting for within the next six months – SOMEguard will be free for all to use and protect their sites against SOME. 


 Ben’s Journey to SOME


What started as disappointment with the old computer and graphic card he had growing up ended up being the beginning of Ben’s journey to security and the SOME attack.  


Unimpressed by the low quality games available for his computer, Ben began tinkering under the hood, and, before he even knew what it was called, he was disassembling and reverse-engineering online games.


“The drive and motivation came from finding more and more flaws that allowed me to trick private game servers into creating special in-game powers via exploiting bugs developers didn’t think of,” he says.


Next-Level Hacking


His interest in computers led Ben to be a leader within the elite data computer network communications team during his mandatory army service, where he learned more about information security and, once finished, began white-hat hacking.


“As soon as I discovered the InfoSec market, the reverse engineering experience and creative thinking helped me reach achievements like hacking Facebook, PayPal, eBay, Twitter, Dropbox, Gmail and reaching up to the Google’s top 0x0a security professionals,” Ben says.


He’s responsibly disclosed bugs at dozens of sites, and was even featured in an article on the New York Post in 2012, having earned over $10,000 in bug bounties in that year alone.


Now a senior security engineer at Salesforce, Ben breaks systems and code for a living and works to try and create web app attacks that hide beneath the Salesforce platform. He’s come full circle from his days frustratingly ripping program code to shreds in order to find kinks. The kinks now are just slightly more dangerous.


What Should You Take Away From SOME?


SOME is a malicious attack, but it’s not the only one of it’s kind. It’s clear from the fact that attacks at least as dangerous as most XSS and CSRF bugs are still being discovered that we have a lot of work to do to not only ensure future applications but also continue securing apps already in use. 


But attacks like this one and the iCloud hack make it clear that application security still has a long way to go, and that we need to both ensure our own apps are tested on a regular basis while at the same time teaching developers secure coding practices like the SOME mitigations discussed above.


About Ben:

Ben HayakBen Hayak, is a Security Engineer and Researcher, whose main interests are reverse engineering, web application security and client-server security. He has several years of experience with Assembler/Assembly language, debugging, and programming as well as three years of data communications experience with CCNA & CCNP Route qualifications. Ben also has extensive experience as a security consultant, surveying the penetrability of data systems and providing practical solutions for organizations. Ben currently works as a security engineer for Salesforce. His expertise include reviewing, isolating, analyzing, and reverse-engineering programs that are vulnerable or malicious code in order to determine and develop protection against the specific nature of the threat. Ben is one of the Top 0xA list of security researchers on Google security list. 


Go Deeper:

  • Read the research on Same Origin Method Execution
  • Watch Ben’s talk on Same Origin Method Execution at last year’s Black Hat Europe conference
  • Follow Ben on Twitter and make sure to keep up with his blog on which he writes more in-depth about about his research.  

Jump to Category