December 18th, 2012, 07:21 PM
Recommended user feedback when abuse suspected?
If you do a GET for information to display and a user writes their own URL with bogus information, and you catch that it is bogus, what feedback do you give them?
E.g., say you have /display-information.php&ID=2
Which results in displaying (non-proprietary) information.
A user, presumably probing for security errors, tries:
or something similar.
I, knowing that I expect an integer, validate the input prior to running my query and do not run a query in this case.
Real users of this system, will NEVER type this URL. (They click a link to get to the information.) Therefore, I know that anything other than an integer is someone screwing around.
I'm thinking the best option is to just tell them "Bad Request" and leave it at that. But I'm tempted to provide a more stern warning: "You entered something you should not have. Your request has been reported to the web master." On the one hand, I'm thinking a hacker newbie might find this unnerving and look elsewhere for security errors. On the other hand, a more seasoned hacker might see this as a challenge and try harder to find a way to break into the system. Since these attacks are most likely being done by bots, it probably doesn't really matter?
When you get invalid input that you know is not simply a valid user's inadvertent error, but most likely someone screwing around, what feedback do you provide?
December 18th, 2012, 07:37 PM
None. Don't reward their behavior with a special message. You can redirect them to a better page (eg, index page), treat the variable as if it were entirely missing (!isset($_GET["ID"])), or force it to be something valid but that won't do anything (such as ID=0).
In general, with security you don't want to give malicious users more information than they already started with. Don't reveal that you detected invalid information because then they might redouble their efforts to find something that gets past your filter. Login forms are a great example: if the username exists but the password is wrong then give them the same "invalid username/password" that they would get if the username didn't exist either, not some kind of "the user exists but the password is wrong" message.
Give as generic a response as possible, or if possible something that doesn't even seem like an error.
Last edited by requinix; December 18th, 2012 at 07:40 PM.
December 19th, 2012, 02:01 AM
"close but no sigar" Nah it's best to provide general instead of concrete information. You sometimes see websites that say sorry that user doesn't exist. Or when you reset a password: we send a confirmation to email@example.com (this potentially allows social engineers, to break in while the client hands over the key himself, i.e by sending fake recovery emails) You can of course log weird attempts, without displaying them.
Originally Posted by EEsterling
Last edited by aeternus; December 19th, 2012 at 02:05 AM.
December 19th, 2012, 01:20 PM
Makes sense. I changed it to look like any other "id not found" error, whilst still logging the inappropriate action.