Using CSRF I Got Weird Account Takeover

Hi guys, I'm back again this bug was interesting and weird let's start.

let's refer to the target's name as ( I start to test the domain like what I do in my testing, I used sublist3r to enumerate the subdomains, in one of these subdomains I start to test the password reset function I sent a request to my email to change the password, i opened the link and sent the request to change the password but i used my Burp to see the request and it looks like that

there is a token for CSRF I tested this token and deleted it but the change happens, that means there is no filtring for this token there is a CSRF bug here and there is another thing the token of reset password not in the request not in the cookies or in the body so i think it's in the sessions and how i knew that? I test the function of reset password I sent another link to my account and i sent the same request but it returns 403, I opened the new reset link bug didn't use it and I go back to my burp and sent the request again and it works and I changed the password with outsend the request from the browser, I understand the function when the user opens the link there is a session will open and will add the token on it and there is something like value to chack like (change=1) if it (1) the server will change the password which comes from the same session if it (0) it will return 403 this what I understand from test the function so now if the user opened the link and didn't use the token it will not be expired and we can use the CSRF bug in this time and we will gain account takeover in this case. 

I liked this bug so I published it, but the subdomain was out-of-scope and I didn't notice it XD.



  1. hey dude ! can i talk with you private this is my profile


Post a Comment

Popular posts from this blog

What can I do with Open Redirect with OAuth?

Exfiltrate data from Blind SQL Injection (Boolean Based) | Using Scripting

Just a DOM-Based XSS