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 🙂
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" :(
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.
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