I have a site with forms and as part of my anti hacking/bot measures I use a security token within the forms (among other things), which I believe is fairly common practice. The processing script also sends a report to me by email whenever something unusual occurs in a form submission to alert me to any attempted hack or bot activity. The report includes an IP lookup on the offending visitor.
Yesterday I got a report in from a problem form submission, the issue was with the security token. What struck me as odd about it was the IP lookup, it was someone local, like within two miles of me.
I have seen plenty of hack attempts on sites and they come from all over the world. This site is primarily of local interest, so the majority of visitors are local.
I got the day’s access log from the server and searched the IP there to track their activity and it first appeared to be a hack.
I see them browsing various different pages, at some point looking at forms, then going to other pages. There is a GET request on one form, then a 15 minute pause. Their next request is a POST on a different form to their previous GET request, but a form that had viewed earlier. That was the only post and coincides with the hack report.
So at first I find this very suspicious, a POST coming from a form another than the last one viewed?
But then the thought occurs to me: What if they viewed the form (that was submitted) then opened another browser tab and continued to navigate the site in that new tab and end up on another form, which creates new tokens and overwrites the sessions for the earlier form? Then they switch tabs to the earlier form and submit it.
Well I thought I would try it for myself, and yes, doing that creates exactly the same reaction and report that user got.
So my question is: has anyone come across this issue before? And do you have a method for dealing with this?
I have already been throwing some ideas around in my head, but not decided on anything solid just yet, and before reinventing the wheel I would see if the clever people here already have something.
I guess one of the points is how strictly you react to this kind of form “error”. If you are confident the offender is malicious you may go nuclear on them. But if there is a possibility of a false positive affecting an innocent, legitimate user, some measures could create a very bad UX.
In this case it blocked them from the form for the duration of their session, which was probably annoying for them, but at least I did not permanently blacklist their IP or something or print a message saying they are a scumbag.
I thought as a quick fix to be friendlier, I could just display some generic error message like “Sorry, something went wrong with your form submission, please try again”.
But really there should be a smarter way to ensure this cannot happen and there are no false positives. Maybe by identifying each instance of a form and associating with its own token.