Hi, I can't figure out one thing. Why, when sending two requests with different cookies and csrf tokens, but with the same name wiener, the tokens for changing the password are the same only if the response time from the server is the same (let's say 360 ms)? When changing the username to carlos, one of the requests cannot achieve the same response time (the first is about 300-420 ms and the second is 60-100 ms), but the tokens for changing the password are still the same. Why is that?
Hey! The question here is if the username is not specified in the URL, how does it know which user to reset the password for? Presumably in that scenario the token in the URL would be associated to the username on the back-end server, i.e. we submit the token and it looks up the username tied to that token and resets the password for it. If the username and the token are linked in this way, I can't see how it would be exploitable.
Hello, do you mind explaining something about response-time and the validity of the token to Carlos user? I hace spent almost 3 hours and never got a valid when I changed the username to Carlos, the message was the same: "Invalid Token" :(
the third chapter "bypass the per...." needs more explanation preferable via something visual just talking it out doesn't stick you simply switched the username ? but in the email log tab it didn't show that they had the same token/?
Hey, I appreciate this chapter may have been hard to follow, especially as the attack didn't work for me first time. I always prepare the solution before recording but sometimes things don't work (*shakes fist at live demo gods*) and I don't know whether to re-record a "flawless" run to make the video faster/clearer or leave in some of the debugging/troubleshooting, which many people seem to like. Let me try to clear up the confusion! Notice at 4:38 we have two emails, at the same time, with the same token? The username is the same here because we didn't change it while testing the different session cookies - we just wanted to confirm that two requests, sent at the same time, using different session cookies, would indeed result in identical tokens. Why didn't we change the username to carlos first? We wanted to visualise how it would look and we couldn't do that without access to carlos email inbox. Finally, since we confirmed that using the single packet attack with 2 different cookies would result in the same token, we repeat the attack on the carlos username (although the first attempt failed, this can happen with race conditions). Let me know if I've missed anything or it's still unclear! I would encourage you to read through the lab material and official solution too as it can help with understanding 🙂
Hi, I can't figure out one thing.
Why, when sending two requests with different cookies and csrf tokens, but with the same name wiener, the tokens for changing the password are the same only if the response time from the server is the same (let's say 360 ms)?
When changing the username to carlos, one of the requests cannot achieve the same response time (the first is about 300-420 ms and the second is 60-100 ms), but the tokens for changing the password are still the same. Why is that?
Hmmm not too sure on that one 😕 Let us know if you find out!
Hello,how would you go about it if the user param(Carlos) wasn't in the url?,plz some highlight
Hey! The question here is if the username is not specified in the URL, how does it know which user to reset the password for? Presumably in that scenario the token in the URL would be associated to the username on the back-end server, i.e. we submit the token and it looks up the username tied to that token and resets the password for it. If the username and the token are linked in this way, I can't see how it would be exploitable.
@@intigriti thanks for the clarification
Hello, do you mind explaining something about response-time and the validity of the token to Carlos user? I hace spent almost 3 hours and never got a valid when I changed the username to Carlos, the message was the same: "Invalid Token" :(
Hmmm IIRC the important thing here is that the session ID must be different for each request, but you also need to update with the new CSRF token
@@intigriti Thank you so much, for your quick replay
the third chapter "bypass the per...." needs more explanation preferable via something visual just talking it out doesn't stick
you simply switched the username ? but in the email log tab it didn't show that they had the same token/?
Hey, I appreciate this chapter may have been hard to follow, especially as the attack didn't work for me first time. I always prepare the solution before recording but sometimes things don't work (*shakes fist at live demo gods*) and I don't know whether to re-record a "flawless" run to make the video faster/clearer or leave in some of the debugging/troubleshooting, which many people seem to like. Let me try to clear up the confusion!
Notice at 4:38 we have two emails, at the same time, with the same token? The username is the same here because we didn't change it while testing the different session cookies - we just wanted to confirm that two requests, sent at the same time, using different session cookies, would indeed result in identical tokens.
Why didn't we change the username to carlos first? We wanted to visualise how it would look and we couldn't do that without access to carlos email inbox. Finally, since we confirmed that using the single packet attack with 2 different cookies would result in the same token, we repeat the attack on the carlos username (although the first attempt failed, this can happen with race conditions). Let me know if I've missed anything or it's still unclear! I would encourage you to read through the lab material and official solution too as it can help with understanding 🙂
@@intigriti thx got it : )
no worries about the recording stuff , you are doing great.