Shouldn’t rely on for sure, but I think for many running legacy software employing a WAF is not unwise, as long as it is configured in such a way that it does not break anything, and it’s not being treated as a way to not fix security problems. At the very least, it can potentially hold back low-skill attacks before patches are rolled out.
I like Signal Science just as a product in general, and have used it to accomplish a variety of security tasks for clients. I am not sold on the core promise of WAF/RASP, where you front an insecure application with a middlebox that resolves security problems for you, and I think I'm squarely in the mainstream of security industry opinion on that.
In a situation where you're saddled with an insecure application you can't touch, I think a WAF can make sense.
In the situation I hope many people are in, where they have a production application they own that they can quicky continuously deploy to - what's the WAF for?
There's a concept that you should use several products in highly secure environments.
For example, if your input validation is written in PHP, you might want to write another layer in front, i.e. in your reverse proxy layer, using something like https://github.com/nbs-system/naxsi. The way, neither just a PHP bug nor a lua bug should defeat you.
In reality, they're probably written by the same person, and thus it's probably a logic bug that will result in a hack and, assuming a zero sum game in engineering time, I'd probably rather focus on protective monitoring than rewriting the same input validation.
But there you go. In much the same way, if you don't really believe you can trust cisco or huawei to protect against their respective governments, then you layer both and hope they keep each other in check.
True @tptacek, but we're talking about systems where you'd rather the system fail closed than leak anything. Not something one would really normally consider for their uber for hedgehogs app.
Personally, I'm not really a big fan of the baseline for the guidence being behind closed doors, I prefer to be able to read said validation, but the guidence does exist and is parroted around the industry occasionally.
Then again, we are in discussion regarding PHP, so someone's bound to point out we're a bunch of neanthardal barbarians just because of that. So it could have been just a kneejerk reaction.
I also suspect this to be the case. However, the reason you get a WAF is because you either want a security blanket or don't have the resources to implement the service in a "good" or... even: "decent" language ;).
I think it's more that you should be aware of the strong limitations they have and weigh that against cost imposed, and what better solutions are available. To take the IDS part for example, I've run Suricata in some locations and we thought of it as I guess a "low hanging fruit picker" for some stuff. Malware authors aren't any more immune to writing buggy stuff, having low quality code heavily made from Google copypaste, and so forth then any other software community. Not all users are running fully patched systems facing modern cutting edge malware either, in some settings you may have people connect running something ancient who click on every single "BROWSER XLR8TER DELUXXEE + FREE CAMS" extension ad they see. So in a few instances it's been a useful, low effort and automated way to notice somebody infected with something dumb and track it down right away.
But there should be no illusions about it substituting for strong network and application security practices everywhere else on the LAN, including some level of isolation. Full BeyondCorp style Zero Trust might not yet be feasible for everyone but there are strong lessons there that can be applied, and at the least that it's very dangerous to blindly trust even a "secure network" just because it's behind a firewall. Which unfortunately is still a prevalent attitude, and IoT is making that even worse for more and more people/organizations. It's unfortunate there aren't more widely available, better and more automated/visual solutions that would make it easier for non-experts to make use of stuff like VLANs and 802.1x. Some things may always take more experience, but I think the pure tech exists to do better then many places are now in terms of network protection and it's more a matter of UX/accessibility.
Also, it's not like it's always free. Even beyond false positives and such, there is a certain amount of hardware needed to run these things as connection speeds go up. When operating on 50 Mbps ADSL then sure, nearly anything can do it no problem, but push that up to 1-2 Gbps or more and at least right now that means significantly more chunky kit. In some places it won't even be a rounding error, but for small businesses (let alone individuals) spending that money should be weighed more carefully.
The article makes it sound like IDS/IPS&WAF are intended to do input validation so it fits the applications model of the data.
They are not.
They are intended to harden the whole stack a little bit against yet undiscovered vulnerabilities.
By the same logic, this "article" could claim that it is possible to abuse Pythons strip() function to bypass WAF rules because filtering for the user name "root" will not filter out " root" and many login systems do strip whitespace before processing the input.
This applies to any language. Here on HN I can log in as "founderling" or " founderling" just fine.
If you want to filter out something in WAF, you 1) have to do it right and 2) do not do it for input validation at all.
It has nothing to do with the language if you fail at 1 and or 2.
If you wonder why PHP does this, I think it comes from our old friend register_globals. In the past, query string, request body and cookie values were automatically made into global variables, so they needed to have variable-friendly names.
Correct, this behavior is well-known and has been around for 20+ years. Leading spaces are removed and additionally other spaces or dots are converted to an underscore.
For this reason, many frameworks ignore the default $_GET structure and instead access the raw URI query in $_SERVER['QUERY_STRING'].
WAF is brittle and breaks more than it fixes IMO. It's just regex against URL's in 99% of cases. If you think you need one, you need to fix the app code, there will be more vulnerabilities it doesn't block
That's an apology every crappy security add-on has always made. We shouldn't be happy about applying layer after layer of faulty controls, let alone applauding that as some kind of defense-in-depth best practice.
(1) Change all underscores in WAF rule URL attribute names to the appropriate non-greedy regex. Though I'm not sure about the regex the article suggests: '.' only matches one character, AFAIU.
(2) Add a config parameter to PHP that turns off the magical url parameter name mangling that no webapp should ever depend on ( and have it default to off because if you rely on this 'feature' you should have to change a setting in php.ini anyway )
parse_str also does not work the same as the parser generating $_GET because it doesn't replace control characters: https://bugs.php.net/bug.php?id=76255
