Web Application Firewalls are a vital component to a healthy security position.Traditional security appliances, like firewalls, are not designed to evaluate all of the intricacies of modern applications.
Traditional firewalls evaluate network layer information, comparing traffic against a list of criteria.For any public web application, the network firewall will be able to block certain attacks but any attacks that use valid web traffic are invisible to the network firewall.Application layer attacks like SQLi and XSS are able to pass through the network firewall unchallenged because they are indistinguishable from normal traffic at the network layer.
Although valid from a HTTP(s) perspective, this is not something you would want to get executed by your webserver.
Web Application firewalls perform a similar function but unsurprisingly they evaluate application information.This means that they are able to block the application layer attacks that pass through the network firewall.
With the network firewall, after all the rules have been compared there is a final default rule that applies to any and all traffic that doesn’t match previous rules and that rule will either accept all remaining traffic or deny all remaining traffic.This final rule categorizes these devices as negative or positive model firewalls respectively.
Web Application Firewalls also come in negative and positive variants and here the differences are even more important.
The positive model WAF has a “whitelist” that specifies what IS permitted.Any requests that deviate from the whitelist are blocked.
The negative model WAF has a “blacklist” that specifies what is NOT permitted.Any requests that match these signatures are considered evil and summarily dropped.
Right off the bat it would appear that if you want your users to get your content without fail the negative WAF would be the way to go.Right out of the box the negative WAF will stop all known attacks and allow unfettered access to everyone else.Because of this the negative WAF has a very low false positive rate.
Positive WAFs on the other hand need to be tuned to your particular application.They need to learn what’s normal, good and valid traffic for your application.This means that right out of the box they are not ready to filter traffic and must operate in a learning mode where nothing is blocked.However, once the learning period is over and the WAF has been tuned to your web application, the positive WAF will have just as low, or lower false positive rate, because even if some of your visitors valid requests would have generated the same signature as an attack, because they are on the whitelist they won’t get blocked.
Where the Positive WAF really starts to differentiate itself is the level of protection offered.With the Negative WAF, your security is only as good as your last rules update, which, when you consider the rate new attacks are published, was already out-of-date when it was published.This is why Negative WAFs are unable to protect against zero day attacks, or new variants of older attacks.
Furthermore the Negative WAF can be fooled by altering a malicious request enough that the signature no longer matches. These evasion techniques won’t be effective against a Positive WAF, because no matter how much you disguise an attack, it still won’t look like the requests the WAF saw and whitelisted during its learning phase.
This SQL injection attack seeks to hide the payload by using character encoding. Even though our WAF has no special signature to match this, DOSarrests Positive WAF blocked it because it did not match known good traffic and flagged it as SQLi (correct) and/or XSS (incorrect).
Senior Application Security Architect, DOSarrest Internet Security