Trusting Pre-domain Wildcard as Origin CSRF Attack — Devfolio
Cross Site Request Forgery (CSRF) attacks are the most common vulnerabilities on the web today, naturally they make their way into the OWASP Top 10. But did you know that there are several different ways in which this can be exploited? Read on to find out how I found a major CSRF vulnerability on Devfolio
Report: Cross Site Request Forgery
Program: Devfolio
Reward: Swag Kit
About The Vulnerability
Most modern websites today make use of a very interesting HTTP Based header technology called Cross Origin Resource Sharing (CORS) to limit its server and resources from unauthorized requests.
In simpler words, for example let’s say you navigate to your favourite website example.com everyday, you have an account on this website and one of the tabs on your browser always serves this website, today you also happen to have navigated to evil.com unknowingly and since example.com has no CSRF protection, evil.com sends requests to it pretending to be you, and the browser automatically attaches all important cookies and info stored to this request making example.com think that it is indeed you sending these requests. As a result, a lot of damage can be done to your personal info/credit cards/banking info etc.
CSRF Protections come in all shapes and forms, but the most common one being the developers writing a list of all websites that are trusted and are allowed to access the resources on this particular website. Then comes lists where a wildcard is added before the domain of the website to allow all subdomains to be trusted. Something like *.example.com
Finding the vulnerability
If a website is using CORS whenever you make a request it sends back a header in its response Access-Control-Allow-Origin which lets the browser know if this is a valid request and if the response should be shown to the request source :
Here * is a wildcard signifying that this particular endpoint is accessible by all the Origins, which is fine as long as this particular endpoint doesn’t expose sensitive data. When you closely look at Devfolio’s edit profile endpoint you can see that, it trusts no other domain other than its own subdomains and itself:
Now let’s try to inject the Predomain Wild Card payload to the Origin header,the response now looks like:
Voila! You see that the server still sent back the Access-Control-Allow-Origin header showing that Devfolio is prone to a Predomain Wildcard CSRF Attack, the CORS policy is only checking for the presence of “devfolio.co” and doesn’t care about any prefix to it like in this case “monishistryingtohackyourdevfolio.co” meaning the validation is something like *devfolio.co. This leads us to believe that the server side code may look something like:
if ($_SERVER[‘HTTP_HOST’] == ‘*devfolio.co’)
{
//Access data
else{ // unauthorized access}
}
The attacker now has access to all the sensitive endpoints. Luckily in Devfolio’s case their cookies were set to strict which meant the browser would not attach the User’s cookies very easily. But since strict cookies are a very new addition, a number of users were still vulnerable.
I urge everyone looking to learn more about this to have a look at this article: https://we45.com/blog/3-ways-to-exploit-cors-misconfiguration
The Reward
This space will be updated once the goodies arrive 😁
