Suppressing errors from failed hacking attempts

[purdue512]

Hey guys - I was hoping someone has a simple answer on this one.

We have error handling on our application (as one should) to shield info from outsource forces. These errors also send us an email - so we can monitor user issues.

We get daily errors because people (we assume hacking programs) are sending POST requests with data such as:

rand%255EX=_tools

rand%5EX=_tools

0x%255B%255D=privangga

0x%5B%5D=privangga

or our fav: 0x%5B%5D=anarchy99

I assume that the illegal characters in the form field name is tripping the error.

Is there an easy way to trap for these?

Thanks in advance for any input.

Don’t forget to tell us about your stack!

OS: ???
Java Version: ???
Tomcat Version: ???
Lucee Version: ???

[Zackster]

there are a few options

• add some filtering at the webserver level
• use cloudflare which has a WAF which often blocks most of these type requests

[carehart]

@Zackster beat me to it–and succinctly, while I was writing my “wall of text” here. I’ll still share it since I do offer a couple more ideas and resources that may help.

I assume, @purdue512, that you’re error handling is catching an error as thrown when cfqueryparam protects you from sql injection, which is great of course.

1] To your question of how to cause error handling to better manage the sending of a flood of such errors, some may want to say “don’t send an email on EACH error, but instead track them in a db and then send an email at intervals SUMMARIZING a group of errors”.

And there are in fact “error handling frameworks”, some written in cfml and some as services (both easy to use), which can imbue that sort of intelligence and more into your error handling. I keep a list of those as a category of my cf411 list, specifically:

https://www.cf411.com/error

2] But still another way to go would be to instead block those kind of hack attempts BEFORE they get to the queries, using any of various OTHER forms of protection, whether at the app, web server, or web app firewall levels. I keep also a list of each such types of protection tools (and a couple more) at:

https://www.cf411.com/protection

3] But finally, the simplest path may seem to be that you could detect in the error handling that the error is a failure specifically of a cfqueryparam, then you could perhaps ignore sending an email about THAT…but then you may miss “legit” failures cause by code mistakes or user input errors…

So then you may consider other options, like perhaps passing the input to any of the various cfml functions that “sanitize” a given string, and so skip sending the error to yourself if the sanitized result differs from the original (meaning it failed the sanitization check)…but that could be an unreliable approach for various reasons…

Or you could choose to skip sending the error if generated from the same ip in several seconds…but then sometimes bad guys do things to change their ip address to hide from such checks…

So then we’re back to, “leave it to the error handling framework makers to alert those things out”. That’s indeed part of why they exist, to “handle this” for us. I don’t know if all of them handle those last 3 issues specifically (and I don’t suspect any handle the second), but a couple are open source CFML, so one could add such new intelligence to them, to help other users.

Let us know if any of these help.

[Zackster]

@purdue512

I assume that the illegal characters in the form field name is tripping the error.

what’s the actual exception? is lucee having trouble parsing the data?

<cfscript>
    dump(server.lucee.version);
    dump(form);
    dump(url);
</cfscript>

<form action=? method="post">
    <input type=text name="0x%5B%5D" value="anarchy99">
    <input type="submit">
</form>

[andreas]

This is what I’d do:

I’d never allow any non-alphanumeric characters and additionally allow only a set of special characters as formfield name in an app, thus I’d loop through every single received formfield and allow a set of whitelisted characters only. If the function finds an unallowed character (e.g. ‘%’), I’d block it right away and offer an captcha to release the blocking. I’d might also log it somewhere just to observe these requests.

But of course, it depends on your app.

[Andrew2]

I shoot first and ask questions later!
I maintain a small (white) list of allowed characters (basicly alphanumeric and a few other chrs such as ‘?’,‘&’,‘=’,‘,’,‘.’ etc).
All requests to the server run through a function that checks for characters not in allowed list.
If non-allowed character is found then the ip address is added to a list of banned ips.
All requests are checked for banned ips, if found return a 404.
Obviously there’s a lot more to it than I have described such as logging, email notification etc.
A succesful hack attack can be virtually instantaneous, better to assume they’re guilty until proven innocent.

[purdue512]

This is all very helpful guys. Thanks…

We are currently looping through all FORM and URL variables in our Application.cfm… The error turns out to be in OUR loop code. Looks like they are sending in a structure in a form field - which was never anticipated… Either way - it’s erroring - which is what we want it to do.

This thread is a good resource. Thanks again. It has given us a few more ideas for even more strict rules for greater protection.

[Terry_Whitney]

A lot of commercial firewalls will help mitigate bad actors before they ever see anything on your network.

That being said, here is what we do

• Check baddies table
• Set and track the user session in a database
• set and track the page with a magic secret based upon session
• check to make sure each page was entered from its expected location
• check each page to make sure access time inst hammered (more than X requests in Y seconds)
• set and then escape and sanitize all output with \ then string and strip the form
  Else
• Send the person to a Technical error
• Log the session, ip, browser, and all other data attempted, set a tracking cookie when possible

[Andrew2]

@Terry_Whitney

Check baddies table

This suggests to me that you are using a list of bad chrs (black list) to check against your input…
It’s more efficient and safer to have a “white list” of acceptable chrs and then if a chr found not in white list act accordingly.

Also it’s better to use a regular expression than a loop (if possible).

OWASP has a lot of useful information:
https://owasp-top-10-proactive-controls-2018.readthedocs.io/en/latest/c5-validate-all-inputs.html

Edit: Use Canonicalize() as well

Canonicalize() :: Lucee Documentation

[Terry_Whitney]

Thanks for that, I may use that in my own script.

Works “baddies” table is a log of browser strings, ip addresses and other logged items.