One thing which i realized here is that at both of the endpoints i.e /post?postId=AnyNumber and /login we have the same csrf Tokens attached to the form which i guess won't be the case every time ... right ?
the script gives the csrf token of the user wiener...who can himself change his email...then how was this a successful attack?...we had to change some other user's email right?...you mentioned we have acces to victim's session....how...coz we don't have the victim's csrf token...I think I am missing something really obvious...
We don't technically have access to the victim's session or CSRF token at any point. It's our code that does. The idea is that when the victim is using his browser, our javascript will execute, causing the victim's browser to send a change password request along with his CSRF token. We are just using the wiener account to help build our script, we are not especially interested in the wiener CSRF token. By the way, behind the scenes, the lab simulates the victim visiting the vulnerable page - this is when the exploit actually happens, so we don't see this on the video. So a completely separate user (not wiener) visits his account and automatically changes his email to evil@hacker.net. We can then request a password reset link to this address assuming we have access to the email account.
@@z3nsh3ll thanks for the explanation...anyways ...the payload gets stored in the server...so we had to demonstrate the technique...not carry out the attack per say...Now I get it...
One thing which i realized here is that at both of the endpoints i.e /post?postId=AnyNumber and /login we have the same csrf Tokens attached to the form which i guess won't be the case every time ... right ?
Thank you for this valuable content. Thank you, but we want an explanation on how to exploit accout take over from open redirect❤❤
nicely explained.
the script gives the csrf token of the user wiener...who can himself change his email...then how was this a successful attack?...we had to change some other user's email right?...you mentioned we have acces to victim's session....how...coz we don't have the victim's csrf token...I think I am missing something really obvious...
We don't technically have access to the victim's session or CSRF token at any point. It's our code that does. The idea is that when the victim is using his browser, our javascript will execute, causing the victim's browser to send a change password request along with his CSRF token. We are just using the wiener account to help build our script, we are not especially interested in the wiener CSRF token.
By the way, behind the scenes, the lab simulates the victim visiting the vulnerable page - this is when the exploit actually happens, so we don't see this on the video. So a completely separate user (not wiener) visits his account and automatically changes his email to evil@hacker.net. We can then request a password reset link to this address assuming we have access to the email account.
@@z3nsh3ll thanks for the explanation...anyways ...the payload gets stored in the server...so we had to demonstrate the technique...not carry out the attack per say...Now I get it...
you the good man how i can earn money
you cant its impossible
why@@dariusvlogs3634
😒