The WAF Dilemma
How I lowered false positives with NGINX App Protect without compromising security.
We are always facing the dilemma "Security vs Usability" in the world of security.
This becomes painfully obvious once you start implementing a WAF. I have now implemented a wide range of WAF security policies, both BigIP AWAF and NAP, and two application functions/features always stand out: file upload and wiki editors.
The core problem with the two scenarios is that they are about handling unstructured data. No matter how hard you try to tune the policy you will have an endless amount of false positives interrupting the end users. If we don't handle this problem correctly we will be forced (aka being demanded by the business) to disable the WAF policy. And that is a loose-loose situation.
What I have constructed is a way to minimize this problem by differentiate between authenticated and unauthenticated end users. In most situations we can have a higher level of trust in traffic that is authenticated and thus tune down on the security. My design is very binary, if you are authenticated the WAF is turned off, if not it is on. This might not be good enough for you but this is only an example on how to go about the core problem. You can fine-tune the solution to be more granular based on the information available like switching the security policy or other mitigating actions. Just remember that having a simple WAF is always better than not having any at all.
You can find the details, configuration and code here: NGINX App Protect with Authentication | Wiki
As always feedback is much appreciated!
6 Comments
- zamroni777
MVP
to avoid waf sqli, xss, etc. false positives of http post payload, the app developer can encode the payload using common base64 then app server can easily decode it back.
https://developer.mozilla.org/en-US/docs/Web/API/Window/btoaencrypting the payload using light cipher such as aes128 is also possible.
javascript can do aes encryption and it will be hardware accelerated.
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/encrypt
https://en.wikipedia.org/wiki/AES_instruction_set- Nikoolayy1
The F5 AWAF/ASM has an option "Do nothing" as shown in https://my.f5.com/manage/s/article/K38690758 (the bd process is used in the two cases so most options should be the same) and I checked https://docs.nginx.com/nginx-app-protect-waf/v4/configuration-guide/configuration/ and the " do-nothing " option seems to be there as well that does not inspect the body. Many use cases and ways to do stuff in Nginx like with F5 BIG-IP and it is great 😀
- lnxgeek
How could I miss that?!?! I have been looking for that specific feature like forever in NAP 😆
It will solve a lot of issues for sure - Thanks!
- lnxgeek
Great input 👍
My problem is usually that I don't have access to the app owners or it is standard software stack where this is not an options.
Even if you pack your payload you will still have issues with the base64 character set which in itself creates a lot of false positive.
- Nikoolayy1
Great article lnxgeek ! I also used " r.internalRedirect " for my use case with request body rate limiter NGINX Plus Request body Rate Limit with the NJS module and javascript | DevCentral but you have also added the WAF App Protect to the mix.
- lnxgeek
When you start to look at NJS your options becomes endless 😆
