Same-Origin Policy Research

David Petty, Jacob Thompson
Independent Security Evaluators

Demo Web Applications (demo.securityevaluators.com):


Cross-Origin Resource Sharing (CORS): login.php
   - Implements CORS response headers
Custom policies (using crossdomain.xml, clientaccesspolicy.xml): login.php
   - View crossdomain.xml here
   - View clientaccesspolicy.xml here

Demo Attack Pages (demo2.securityevaluators.com):

CORS: CSRF_cors.html
   - Visit while logged into the CORS web app
   - Sends POST request that forces victim to buy 1000 apples
Flash: CSRF_flash.swf
   - Source: CSRF_flash.mxml
   - Visit while logged into the custom-policies web app
   - Sends GET request to editCard.php so attacker can steal victim's credit card #
Java applet: CSRF_java.html
   - Source: CSRF_java.java
   - Visit while logged into the custom-policies web app
   - Sends POST request that forces victim to buy 1000 apples
Silverlight: CSRFSilverlightTestPage.html
   - Source: App.xaml.cs
   - Visit while logged into the custom-policies web app
   - Sends POST request that forces victim to buy 1000 apples

Summary:

The purpose of this demo site is to demonstrate the dangers of weakened Same-Origin Policy configurations. The Same-Origin Policy dictates that one webpage cannot access data on another webpage through JavaScript unless the two pages share the same origin, and a resource's origin is simply defined as its protocol, host, and port number. This policy is very important because it restricts sending server responses to webpages attempting to access data on other websites through cross-site requests. Without this policy, attackers can trick victims into visiting malicious links that expose sensitive information to the attacker, e.g., profile information, credit cards, csrf tokens, etc.

Due to the need for developers to open their applications to third-party sites for functionality, there are ways to configured the Same-Origin Policy to allow custom policies that whitelist domains. However, issues arise when web servers whitelist too many domains because the more domains that can access data on a site, the more likely an attacker can exploit the site's users. The Same-Origin Policy can be configured through a number of ways:

The demo web applications listed at the top of this page all utilize insecure Same-Origin Policy configurations that whitelist all third-party domains. The attack pages give examples of how users of such web apps can be exploited simply by tricking them into visiting a malicious link. It's also important to note that CSRF protection is implemented in the web apps because this protection is bypassed when the attacker obtains the CSRF token in a response from the server (a secure Same-Origin Policy would block this response). This is utilized by the attack pages that force the victim to buy 1000 apples.

Using the Web Apps

To see the Same-Origin Policy misconfigurations in action, simply visit one of the two web applications and log in (credentials are customer:password). Feel free to explore the functionality of the web apps; you can buy apples or update your credit card. This functionality is simply to demonstrate different types of exploits (i.e., forcing a victim to buy apples or retrieving the victim's credit card). To simulate an exploit, you then visit an attack page while still logged into the web app (this would be an attacker tricking you into following the link).

Before visiting an attack page, it will be useful to open your browser's developer tools or some network traffic monitoring tool, such as Burp Suite, to view the requests and reponses. If you are logged into the CORS web app, visiting the CSRF_cors.html attack page will cause you to buy 1000 apples. You can then refresh the Main Page and see the number has increased. The CSRF_java.html and CSRFSilverlightTestPage.html attack pages execute the same attack on a user logged into the custom-policies web app (second link), but are limited by the fact that the respective plugins need to be run by the victim user. This attack works because the attack pages first make a GET request to mainpage.php which responds with the victim's CSRF token (again, a secure SOP policy would block this response). The attack page then extracts the CSRF token and uses it in a POST request to buy.php with a quantity parameter of 1000. The server validates this request because it contains the victim's CSRF token and session cookie (browsers send cookies cross-origin by default).

I wrote the Flash attack page differently simply to demonstrate a different type of attack. While logged into the custom-policies web app, if a user visits the CSRF_flash.swf attack page, a cross-domain GET request is sent to editCard.php. Since this webpage displays the user's credit card #, the response will expose this card information to the attcker. Normally, the Same-Origin Policy would block this response.