I was preparing myself for the Hacktivity conference in Budapest, where I talked about the security of the Cross-Origin Resource Sharing (CORS). As part of the preparation I summarised my thoughts in a couple of blog posts. This is one of them.
As a follow up of my previous post, I would like to continue with the short analysis of the threats and attack scenarios which could exploit CORS.
There are a few things to consider here. First, that CORS is not broken. It is just a feature that can support other already existing attacks to exploit other vulnerabilities. From penetration tester point of view CORS is rather a tool, then a vulnerability. Second, the most important property in CORS is that it allows you some kind of pass through the same-origin policy with a handful of limitations.
First let’s see the possible attacks from three different perspectives:
- Goal of the attack
- Target’s location
- Type of attack
1) Goal of the attack
To start off with, it is worth to understand what kind of goals can an attacker have in mind.
Exploit Cross-Site Request Forgery
Interact with the internal network
If the user loads the attacker’s website in the company network, that essentially means that the attacker can execute code in the internal network. Of course some pretty strong limitations apply, which I will describe in the ‘Limitations’ part. So in this case the attacker can use CORS to try to explore the network, find well known service, try to do simple scanning etc.., or simply attack a known internal service which he has no access to.
2) Target’s location
Another important aspect of attacks is the location of the target. Here when we say ‘target’, then the target service is meant, so not the user who loads the malicious content but the service, which the hacker wants to attack through CORS.
Attacking services on the Internet
Attacking internal services
3) Direct vs Indirect
Direct attack against services
The indirect attacks are the traditional client side attacks, when the malicious code is injected in a website, that has to be loaded by the user. When the page is loaded the malicious code attacks the target service from the user’s client.
As mentioned before there are pretty strong limitations when using CORS.
Write only requests
withCredentials vs. Access-Control-Allow-Origin: *
Although these different perspectives are a little redundant, but all the different attack scenarios can be built from the combination of them.
Since this is only my quick analysis, if you have other ideas to the topic let me know.