Or, "why you shouldn't rely on IDS, IPS, and WAF".

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.

For anything?

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.

This is usually a better way to get multiple single points of failure than it is to get a more resilient system.

You can click on the timestamp of a comment and reply to it there so you don't have to @ people like a barbarian.

You can give the usability information about this website without calling a group of people barbarians.

I jokingly compared a single person to a barbarian without calling anyone a barbarian, like a barbarian.

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.

Yes. Needing any of these to secure your application means the app code is broken.

Every WAF I've used breaks URL's randomly because they're just pattern matching against known attacks to a definitely broken system.

Any properly engineered system is invulnerable to all attacks a WAF would catch at the HTTP level

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.

If you do positive validation, you probably won't be affected by this.

In other words: check that the id is a string with digits only.

Don't search for invalid characters like ASCII NUL or for clever escapes, because there are too many ways of abuse.

Use ctype_digit() for numerical ids and stop with a validation error if ctype_digit() does not return TRUE.

https://www.php.net/manual/en/function.ctype-digit.php

For more complicated cases (like an id with lowercase letters and digits) preg_match() can be used, for example: preg_match('/^[a-z0-9]+$/').

Nothing is abused, nothing is bypassed.

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'].

Seeing a lot of WAF-hate. Additional rules could fix this.

Flame-bait Proposal:

Or, "why you shouldn't use PHP" or any other language the silently converts badly-encoded input for you?

Hrm... the solution is to keep your PHP codebase up to date...?

The solution is to throw out your WAF.

WAF has it's purpose but it's clearly not a silver bullet. Nothing is.

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

WAF provides a lot of other things, such as IP based filtering.

If it's so easily circumvented I wonder if it's worth the costs.

Disagree. This just reinforces the point that best security is multi-layered.

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.

WAF are basically all HTTP proxies. If you app has a non-broken HTTP implementation they're useless.

yup, WAFs, IDS and IPS prevent protocol abuse. Everything else is the development teams problem

Possible solutions:

(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