I recently noticed an uptake on Cross-Origin Resource Sharing (CORS) findings showing up in automated scanning tools, which would not have been a significant concern except for the fact that the tools were rating this as a relatively “high” severity and very few people I asked about it seemed to have any idea what it was. I love to find obscure quirky behaviors that can be turned into vulnerabilities… but first it we need to determine whether or not it is as bad as the scanning tools lead us to believe.
So what is CORS?
Simply put: it’s a mechanism that creates a contract between a browser and a server permitting an exception to the Same Origin Policy. This is an extremely important aspect of today’s application mashup dance party where all sorts of applications are intentionally interacting with each other in dynamic ways which must work around the Same Origin Policy. It is accomplished through request and response headers in such a way that the browser will identify all script-based requests with an Origin header, to which the server will respond with a set of cross-origin restrictions. The browser will only proceed with sending requests that adhere to the restrictions. The whole thing is slightly more complicated than this so if you want more details I recommend giving this a read: http://www.html5rocks.com/en/tutorials/cors/
Now the really interesting part of this from a penetration tester perspective is when we start involving cookies. It is possible to use CORS in what is known as a “with Credentials” mode, which will in fact send cookies during a cross-origin request. By this I mean that if you establish a session cookie with one origin, that cookie will be sent during any CORS requests (from other origins) to that origin. This allows a cross-origin request (e.g. an AJAX call) from one site to interact with another site as if the user was logged in.
So here is the line the scanning tools complain about:
…and I see why. With a global wildcard policy like this (on any site containing sensitive data), wouldn’t that mean a user browsing any attacker-controlled site is at risk of a cross-origin call pulling data off the target site? Researching this did not yield a satisfactory answer so I decided to write some test code and experiment with some scenarios on a few different browsers to see how they reacted. I tested Firefox 31.0, Chrome 37.0, and Safari 7.0.6 and all three of these yielded the same results.
What’s the Risk?
So what does this mean for penetration testers? I feel we have not yet reached the end of the story. So far my testing suggests that it is not common practice (yet) for servers to filter response based on Origin headers. At a minimum this means the responses of an overly-permissive CORS policy can be easily captured by a proxy. So an overly-permissive CORS policy combined with lack of Origin filtering and cleartext (HTTP) communication sounds to me like a solid recipe for data theft.
Want to talk about it?
I will be teaching a Web Penetration Testing course at AppSec USA next week and would be happy to discuss this research.
Jason Gillam is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at firstname.lastname@example.org, on Twitter @JGillam, or visit the Secure Ideas – ProfessionallyEvil site for services provided.