21–30 of 33 posts
Or, "why you shouldn't rely on IDS, IPS, and WAF".
Flame-bait Proposal:
Or, "why you shouldn't use PHP" or any other language the silently converts badly-encoded input for you?
Earlier quoted context omitted.
For anything?
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
Earlier quoted context omitted.
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…
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.
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.
For this reason, many frameworks ignore the default $_GET structure and instead access the raw URI query in $_SERVER['QUERY_STRING'].
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.
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]+$/').
Earlier quoted context omitted.
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.
You can click on the timestamp of a comment and reply to it there so you don't have to @ people like a barbarian.