Pentesting CORS

Give me all your cookies! OK.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

🔒 Related Stories: Penetration Testing

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Have you ever tried to create a micro-service on one domain that displays web content, and then access it from another domain but got an error saying that it wasn’t allowed? This error message was possibly due to a CORS (Cross-Origin Resource Sharing) policy. Web browsers try to prevent one website from loading data from another web site without permission to protect sensitive data. The browser only retrieves the data if the website has a CORS policy that allows that other domain to do so. Sometimes developers get this error and fix it by allowing any other website to make requests via a CORS misconfiguration (via a * for the allowed domains in the CORS policy). Pentesters can look for issues in CORS policies to try to obtain sensitive data and take otherwise unauthorized actions.

What could go wrong if you allow any website to access content on your website? Let’s say you log into your banking web site and it uses cookies to help determine if actions are allowed. What if I could trick you into visiting my evil website and then my evil web site, in turn, calls your banking website invisibly behind the scenes. My website sends a request to the banking website. The banking web site returns the requested information — and all the cookies for the logged-in user. Then my evil site makes a request using your cookies to the banking website that asks it to transfer all your money from your account to mine. Cool for me, right? Not for you.

How does that work? Well, one website has a domain (like evil.com). Typically the browser blocks it from accessing data on a different domain (like bank.com). The browser says, “Nope, that’s a different domain. You can’t have that data.” However, let’s say the bank set up a CORS policy that tells the browser, “No, it’s cool. Let anyone access my website information.” The browser checks the policy and sends any website the information it requests from the banking site — along with cookies (depending on a few other things as I’ll explain in a minute). If the attacker can get cookies that allow authorized actions on the site, then presumably the attacker can take actions on the user’s behalf.

If an evil site is sending the request to the banking site, it might do this via an invisible iframe (set height and width to 0 or coordinates that display the content off the boundaries of the page) or AJAX request. You won’t see it or even know this request is in progress unless you look at the source code. If the bank also did not correctly secure cookies, the request would send back sensitive data in cookies along with that request. Those cookies may be controlling state and authorization, which in turn allows the bank transfer in my evil scenario.

It’s not quite that simple. CORS has different types of policies and controls — certain types of information may or may not be passed depending on these settings. I’m not going to go into all of that in this particular post — but now that you know what can happen, if you’re on the defensive side you want to make sure you have a restrictive CORS policy that only allows your website data to go to trustworthy sites and send only the data you intend to send to that site. Even if you trust the other site, if they, in turn, have a security flaw in their website code, it could affect your site. Choose wisely. You might consider using something other than cookies for authorization of actions on a web site since any mistake in CORS might end up sending cookies where you don’t intend them to go.

On the pentesting side, I could try to explain all the things you can do to attack CORS, but I’m going to instead refer you to this fantastic video on CORS exploits at AppSec Europe called AppSec EU 2017 Exploiting CORS Misconfigurations For Bitcoins And Bounties by James Kettle. This video is full of funny stories and examples. One demo shows how a CORS misconfiguration allowed various unintended actions on a Google Finance website. There are some simple things you can do to see if a site has a CORS misconfiguration as well via a post request to see what data the web site returns. You can see what types of requests you can make to the web site and what cookies it returns in the header information.

One of the pitfalls of CORS, as that video explains, is the fact that CORS doesn’t allow you to list multiple websites in your CORS policy. You can only list one. What if you have several subdomains for your different microservices? Some people mistakenly used jsonp to get around this limitation and other flawed approaches that end up solving one problem but introducing other security errors.

To get around this one domain limitation in CORS policies, you can write additional authentication logic on your website. Even though CORS allows all websites to make a request, your application validates and authorizes those requests or not via other means. Another solution is to add a Content Security Policy (CSP). This type of policy helps you create much more granular controls and make it harder for pentesters and attackers to abuse your CORS policy. The CSP can limit which sites can put your site in a frame, for example.

A word of warning if you are using a CSP and integrating with other web sites — test it carefully! I was working through an issue with a banking site where everything was working, and then a CSP was applied. The result was a blank page on an integrated site. I had to dig into the developer tools to find the error message. Test your CSP carefully before you roll it out. Make sure you test both in your test environment and production, where different domains and subdomains may exist, requiring different CSP settings in different environments. Make sure you only allow what is required. For example, don’t allow your test domains in production — another thing pentesters can check for when testing a site.

For pentesters and developers, as the video above mentions, read the CORS specification. You will probably find some ways to abuse incorrectly configured CORS policies, or learn how to fix problems on your web site. If pentesters don’t find a CSP in place on a website and the site is using cookies for any sensitive data or authorization, for example, try to see if you can find and abuse a CORS misconfiguration and make cross-domain requests to obtain data or make transactions that should be unauthorized.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2019

The best way to support this blog is to sign up for the email list and clap for stories you like. That also helps me determine what stories people like and what to write about more often. Other ways to follow and support are listed below. Thank you!

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
Author: Cybersecurity for Executives in the Age of Cloud
Presentations: Presentations by Teri Radichel
Recognition: SANS Difference Makers Award, AWS Security Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Software Engineering, Master of Infosec
Company: Cloud Penetration Tests, Assessments, Training ~ 2nd Sight Lab

Like this story? Use the options below to support this blog.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Clap
❤️ Referrals
❤️ Medium: Teri Radichel
❤️ Email List: Teri Radichel
❤️ Twitter: @teriradichel
❤️ Mastodon: @[email protected]
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
❤️ Buy a Book: Teri Radichel on Amazon
❤️ Request a penetration test, assessment, or training
 via LinkedIn: Teri Radichel 
❤️ Schedule a consulting call with me through IANS Research

Cybersecurity for Executives in the Age of Cloud