🟥How Easily I Found My First P2 on Bugcrowd
The Very Basic CSRF with some good tips
Hey 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.txt
sublist3r -d foo.com -o subs2.txt
cat 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 alive 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

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! 🐜🛠️
Last updated