BOOK THIS SPACE FOR AD
ARTICLE ADHey Hackers, This’s mrhashimamin And today I’ll talk about my first P2 ( high ) bug that i found on a Vulnerability Disclosure Program ( VDP ) on bugcrowd ( Let’s call it foo.com ).
The story began when I encountered a duplicate race condition mentioned in my last write-up. After that, I found a NOT APPLICABLE IDOR in the same program, so I decided to choose another program.
I selected a new VDP on Bugcrowd, which is an American football site with a large scope and many functions to hack xD. And That’s where I found my first CSRF on a subdomain ( sub.foo.com ).
Cross-Site Request Forgery ( CSRF )
Cross-site request forgery ( also known as CSRF ) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform. It allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other.
To know more about CSRF, check this.
How i did it?
After choosing a program, I started with the basic recon process: subdomain enumeration, identifying live subdomains with httpx, and gathering some endpoints using gau.
subfinder -d foo.com -o subs1.txtsublist3r -d foo.com -o subs2.txt
echo subs1.txt subs2.txt >> subs.txt
rm subs1.txt subs2.txt
httpx -l subs.txt -threads 200 -o alive.txt
cat alive.txt | gau --subs --blacklist png,jpg,jpeg,svg | tee endpoints.txt
While the recon process was running, I started with the main domain ( foo.com ). It’s like a blog or news site with main functions such as sign-in, sign-up, reset password, update user data, delete account, and more.
As usual, I signed up and started with the reset password function. After numerous tests, I discovered that changing the host header to ( evil.com ) redirected me to ( evil.com/some-path-to-send-reset-token ).
However, it needed a cache poisoning vulnerability to become a valid open redirect. Despite a lot of effort and tests, I found nothing :(
So, I wiped my tears and continued my process. I tested various parameters for XSS, SQLi, SSTI, and SSRF but found nothing. I also tested the user data change functions for CSRF and IDOR, but again, found nothing.
But what about my recon? I checked the alive.txt file and tested the live subdomains one by one. I encountered some 403 and 500 errors and found some new targets. After fuzzing some of these new targets, I still found nothing useful.
Now i see some good targets. Like this one, It’s an auction site. Users can pay money for some stupid useless American football players’ belongings like shoes and shirts xD
Guys, Are u really spending money on this???However, this app also includes basic functions such as sign-in, sign-up, and password reset. During testing, I discovered that users can change all of their data by submitting just one form! (Looks like someone put all their eggs in one basket xD).
So, It seems there’s no validation on it, It’s clearly vulnerable to CSRF.
Step by step
1- I’ve crafted a CSRF Attack page and saved it at my localhost
2- I opened it in Firefox while authenticated.
And yeah, we finally did it!
Unfortunately, they marked it as a duplicate. But since it’s a VDP, it’s not a problem for me.
Thanks for joining me on this bug-hunting journey! Your support rocks. Let’s keep squashing bugs together! 🐜🛠️