11–20 of 33 posts
Earlier quoted context omitted.
The solution is to throw out your WAF.
Disagree. This just reinforces the point that best security is multi-layered.
Earlier quoted context omitted.
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?
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.
Hrm... the solution is to keep your PHP codebase up to date...?
The solution is to throw out your WAF.
(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 )
Earlier quoted context omitted.
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…
Or, "why you shouldn't rely on IDS, IPS, and WAF".
For anything?
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
Or, "why you shouldn't rely on IDS, IPS, and WAF".
For anything?
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.
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
The solution is to throw out your WAF.
WAF has it's purpose but it's clearly not a silver bullet. Nothing is.
Earlier quoted context omitted.
Disagree. This just reinforces the point that best security is multi-layered.
WAF are basically all HTTP proxies. If you app has a non-broken HTTP implementation they're useless.