The user opens the email, clicks the link, and is directed to a “change password” page in Web2.
Works great! Or it used to.
Recently, I’m seeing that something is going to that web page before the user ever reads the email. I’m pretty sure that anti-malware scanners (either in the ISP’s SMTP mail system, or on the user’s local computer) are opening the URL to check it for bad things.
The problem is that this malware scanner is opening a session inside Web2 which leads to the user’s password being reset, even if they never clicked the link!
My question: Is there any way, in the Session.Opening() event, to detemine if this is a real user or vs some sort of bot?
check in the App.HandleURL for specific items, then redirect by 303 See Other to your session based handler store cache on the App class or leave the url parameters on the url
“https://example.com” or “Example Domain”
Only afer the user fills in the details and presses “reset password” we allow the password to be changed. Then we notify the user that it was successful (and he may report it if required).
I’ve never seen such behaviour, perhaps it’s what greg suggest, a really enthousiastic user?
I decided try something similar to @DerkJ - upon recieving the ‘reset’ page, the user is routed to a special WebPage, which shows a WebMessageDialog. Only when they click “Yes, reset my password” do we do the actual password reset.
I’m pretty sure this will stop most robots, since I think many of them don’t run Javascript, and even if they do, they probalby do not also click on random UI elements.
Testing it now, will report back how it’s working.
yeah, users can do headlesschrome also from the terminal. But it could be a (spam/malware) scanner bot. There is ways to go around this but yeah this is how one could exectue all javascript. Maybe you can detect this via javascript and block it?
I’m in camp “much more likely just a link preview bot that’s been designed to render JavaScript”
My suggestion would be to not invalidate the link immediately, but to wait until the user has chosen a new password so that link preview bots don’t unintentionally deactivate the link.
But the hash and the user are visible in the URL That is really insecure. It is better to ask for some information that it is not in the URL to be sure that only the user can reset its password.
I don’t get your point here - the URL is sent to a specific email address, so asking “for the email” doesn’t add any security, since the email address is in the email, by definition.
Maybe I misunderstand?
The way I see it, the only security risk here is if someone has lost control of their email account, and in that case, pretty much all bets are off for doing a password reset via email.