Web2 : detecting bots

I have a pretty fancy Web2 site which works well. One part of it is a password reset feature, which emails the user a URL to click, like this:

https://example.com/?page=reset&user=mike&reset=F547D0F34F4D9987

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?

It also could just be a hacker trying it out.

Start by checking if there’s a user-agent header. That’ll at least tell you that it’s a browser.

I suggest doing that in App.HandleUrl before the session is created though

we have such system where we normally use App.HandleURL with a url path other than the session based app to for example path “action/pwreset”:

https://example.com/action/pwreset?page=reset&user=mike&reset=F547D0F34F4D9987

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?

1 Like

Good ideas all, thank you.

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.

I’m 99% sure it’s some sort of bot, for example here’s a sample browser string:

[2023-01-20 11:05:26] Session.opening page=‘reset’ opened from xxx.169.39.63 size=1600x1200 browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,like Gecko) HeadlessChrome/104.0.5112.101 Safari/537.36

Notice HeadlessChrome

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.

That is something, but it is stil risky. It is better to ask for some data to confirm identity, for example the email.

Good point - another category of bots which are going to “secret” URLs in emails that may not be malicious, but are certainly annoying.

Of course - the URL that is clicked requires a username (email) and a one-time random hash. Without that, no password reset is allowed.

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.

But you said:

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.

Is there another scenario you are considering?