Question, I found that www[.]example[.]com/media/scripts is forbidden (403); however, I fuzzed a little bit and found that I can still view a csrf-token.js file which shows how their CSRF token works. Basically it shows exactly how it’s activated and only works with POST requests. Probably something that they don’t want people to see… is this a valid find? I just want to make sure before reporting garbage, but, to me, it seems like a good find maybe?
1 Like
Hmm, I’m not sure I quite understand. Does the endpoint leak the user’s CSRF token? If so, you can probably create a CSRF exploit that collects the token and uses it in the forged request. That would be a site-wide CSRF vulnerability (P2, I believe).
Otherwise, it might be considered a valid WAF bypass or data exposure bug. You should try to exploit the exposed information further, but if you can’t, I’d still report it.
1 Like
@waike, no, the endpoint doesn’t leak the user’s CSRF token. I really haven’t figured out a way to go further with it. I’ve been trying to fuzz for other files to see what I could find, but that’s the only one I found so far. I agree, and that’s what I was thinking too, either way it seems like a WAF bypass / Access Control bug. In my opinion, if that whole directory is 403, it doesn’t make sense why they’d make files in that directory, especially Javascript regarding their CSRF tokens, public.
1 Like
I’m pretty new to bug bounties but as a software architect I can make a guess though. If they have a login page they want to use to generate csrf tokens, they need to be able to protect the login action without being authenticated. Which requires the csrf end point to be available.
This doesnt mean it’s a good or a bad thing, but I can understand the logic. Real question is, how do you exploit it?
The thing is, normally csrf tokens are used both in frontend and backend and when a request is submitted you compare the 2 to make sure the request came from the original user.
Just having the generator exposed might mean that they generate a csrf token, send it to the server with a login request and then the server stores it for later verifications.
The problems come when you can either start guessing the csrf because the algorithm is weak, force people to use a provided csrf token, expose the csrf token over an http connection (although mitm attacks are often out of scope), do old csrf tokens still work, maybe the backend doesnt verify the csrf belongs to the user and only checks if it’s a valid one?
And all of these are only valid issues if you can somehow let the user make a request to the server without them knowing using Ajax calls etc or you are able to steal login tokens without having the actual credentials.
Hope this helps.
@Gekko09, thank you very much! That was extremely helpful. I couldn’t find a way to exploit it, I was just wondering if bypassing the 403 page was enough. I am very weak in javascript, I can get by with the basics, but I can’t read a file and be like, “Oh, I understand their algorithm now, let me try ‘x’ to break it now.” Thank you again, much appreciated!
you found a csrf-token.js file which shows how csrf tokens are generating on the client side? if this is the case then do as @waike have told you to use that csrf tokens to forge a request. if that is not the case then can you elaborate your question.
If you can share a snippet of the code you think is vulnerable, it would be helpful.