No WAFs

Your security team has just painted a grim picture of potential cyber threats, and you’re aware that your web application is a minefield of vulnerabilities. Fixing these security issues seems like a task that could take between forever and never.

WAF, not what you hoped

But wait! There’s a solution, a Web Application Firewall, which catches common vulnerabilities like injection attacks and Distributed Denial of Service (DDoS). No coding is needed. You just direct all web traffic to the WAF; the WAF inspects all HTTPS requests and blocks the dangerous ones.

WAFs operate by inspecting all HTTPS requests directed towards your web application and blocking any that seem dangerous. They decrypt HTTPS requests and scan the headers and body for potential threats to block based on content, IP address, or request patterns.

Additionally, WAFs offer protection against DDoS attacks by blocking sudden surges in traffic. This can be done with simple rules such as the rate of requests and the IP addresses of the source. Alternatively, WAFs can use artificial intelligence to detect the access patterns typical of DDoS attacks and block those.

Don’t do it.

The WAF is a mistake. Here are some reasons why:

Blocking Your Own App

WAFs can block legitimate users from accessing your web application by mistaking normal activity for an attack. In fact, your web-app quite likely requires input that has “suspicious” strings in it, and the regular expressions will erroneously catch those: For example, if your app serves technical customers, you may have snippets of JavaScript that look like an attack. Worse, your app may require fundamentally dangerous input: For example, if it accepts HTML from a rich-text web-editor component and renders that directly, then I can tell you what you know already: That you could and should escape the strings, not pass around the equivalent of an attack. But rooting out such weaknesses, once created, is hard, and until you can allocate your team to doing that, the WAF will make your web-app unusable.

For DDOS protection, the WAF blocks sudden increases of traffic, but that invites the worst sort of false positive: The kind that happens when your app goes viral, and your visitors can’t use the web-app. This is why the WAF’s advanced filtering, driven by machine learning (ML) can help. Though not perfect, it is better than the pattern-based approaches of most WAF filtering.

Blocking individual IP addresses is obviously too fine-grained, so the next step is blocking entire countries, excluding customers from an entire country. Perhaps you are not serving customers in that country today, but with the WAF, you also prevent yourself from discovering potential new markets.

The recommended approach to deal with false positives is to set up the WAF in dry run mode, so that when it would otherwise block, it writes log on suspicious input. Next, you analyze the logs to see if there are false positives, and if so, either loosen the rules (so potentially ignoring some real attacks) or else fix up your code (but you’ve been putting that off for years already). I have seen organizations dry-running the WAF for two years because of a quite justified fear of ruining their own app’s functionality. So, they slowed down their app, got no security benefit–and spent tens of thousands of dollars in license fees, without ever getting any security benefit.

Letting Attacks Through

The variety of possible new attacks is beyond the imagination of WAF designers and yours; but not of the hackers. This leaves you with the false positive’s mirror image, the false negative: Real attacks that are let through.

The regular expressions that are the most common way to filter text are limited in what they can detect. They must be predefined for specific attacks and have to be kept simple for fast processing. For speed, only the first few kilobytes of the HTTP header and body are scanned; and even if you increase that, there must always be a limit beyond which attacks are let through.

Blocking IP addresses is also a source of false negatives, as attackers can easily shift to use new IP addresses using proxies.

The main source of attacks that WAFs can do nothing about, is in your own application logic. If a page was meant to be password protected and is not, or if the authorization allows a user to write data when only reading should have been allowed, it’s on you. Though no one expects WAFs to find such vulnerabilities, they emphasize that the main place to implement web security is in your own code.

Flexibility?

As you pick your way through false positives and negatives, it’s tempting to tune the rules and customize them precisely to your needs, or even to build your own. Don’t.

Security experts have already researched the types of attacks used by hackers. Hackers are not going to invent special attacks for you, or if they do, you too won’t know it in advance. Your app’s vulnerabilities are almost certainly the same ones found in the standard rulesets. If your app actually does have weaknesses so special that you need to diagnose them and write new protection rules, you should instead spend that development time not on the band-aid but on improving the app itself.

Balancing accuracy and recall — false negatives vs. false positives — is difficult-to-impossible even for the experts. They define protection levels to let you make the trade-off between false positives and false negatives. Refining that balance against millions of potential future web requests is not worth it.

Added Risk

These drawbacks usually make WAFs a net negative. But more, WAFs themselves can pose a security risk. They have to decrypt HTTPS to inspect the data, creating another potential point of data leakage; WAF code itself could have vulnerabilities. Plus, they can slow down communication as every request passes through them.

Too often, even knowing all these facts about WAF, managers decide to add one anyway, as a stopgap, planning to fix security vulnerabilities later. But once the WAF is in place, the team becomes complacent, and proper security practices are never adopted; the application code just gets less and less secure. Meanwhile, the WAF is not actually providing the imagined security

Despite these drawbacks, there are situations where using a WAF might be advisable, though you still won’t get much security out of it:

If you have an external requirement that demands a WAF; if a customer’s Request for Proposals or industry regulations require you to conform with a formal security standard, then of course, add it: The WAF is necessary, but not for security,

If you are deploying a third-party web-app, one that you did not develop, and can’t fix, then a WAF may be your only path to adding a bit of security. You still risk complacency about your true security level, but at least in this case, you’re not pushing yourself farther off the road to good development practices.

That said, there is one good security reason to use a WAF: DDoS protection. When a Denial of Service Attack sends massive traffic, your WAF can detect attacks and block them. The detection of attack patterns with ML, gives good accuracy.

For further DDOS protection, having a team of human experts ready to respond, as in Google Cloud Armor Managed Protection and AWS Shield Advanced, is worthwhile for the largest web-apps.

A lot of customers reach out and try to urgently buy DDOS protection services, whether a WAF or the expert teams, after the attack has started when there is no time; consider putting it in advance.

If you are going to use a WAF, then use the one offered by your cloud provider: Google Cloud Armor, or AWS Shield. With the cloud services, you pay as you go, as opposed to committing to an expensive monthly fee for a product you might not actually use. Also, since the data is already flowing through the cloud, and in many architectures, cloud services decrypt your data anyway, using a WAF service from your cloud provider minimizes the impact on performance, security, and privacy.

See this article by Mac Chaffee and this StackExchange thread for valuable technical details on these points.