The Problem with Signature-based Web App Security

Posted: January 29th, 2015
Filed under: IIS & HTTP

In the real world we have the benefit of being present and able to see and analyze scenarios in real-time. In the cyber world, we rely on code and algorithms to handle millions of complex tasks every day without much real-time human intervention. Unfortunately, one of the tasks that we leave in the hands of technology is web security.

This is a problem because unlike humans, code and algorithms cannot decide what is good and bad. Not from a philosophical moral perspective (humans still struggle with that), but from a security standpoint. In order for web security tools to know if a user is doing something bad it needs to be programmed to know what specifically to look for. The way that many tools know how to detect malicious actions or activity it by using attack/threat signatures. This may make for a great business model for those who sell such products, since they can sell signature updates, etc, but it makes for a dangerous security model.

What are signatures, anyway?

So what are signature-based rules, exactly? One way to envision them are as a glossary of different threats that a security tool can reference to know whether or not it should take action against inputs. A signature is typically based on an exploit that has already occurred and has been documented. The signature details the way that the exploit works using a series of parameters to indicate the specific actions that occur during the exploit.

This model depends on matching inputs to a specific signature in order to block them. This can be likened to taking a fingerprint of someone who wants access to something and comparing it against a database of fingerprints of known criminals. This will work great for stopping frequent criminals, but will never stop the first-time offenders.

Example rule:
'Cross-site Scripting (XSS) Attack',id:'958016',tag:'OWASP_CRS/WEB_ATTACK/XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/WASC-22',tag:'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/IE1',tag:'PCI/6.5.1',logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.xss_score=+%{tx.critical_anomaly_score},setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{}-OWASP_CRS/WEB_ATTACK/XSS-%{matched_var_name}=%{tx.0}"

The problem with security tools that rely on fingerprint matching is that fingerprints are unique, and the fingerprints for attacks that haven’t happened yet don’t exist. That leaves a gaping hole in these tools ability to provide security.

Good luck stopping zero-days!

Since signatures only account for what has already been seen, they don’t do anything to account for what has yet to be seen. When a new, never-before-seen, zero day comes along the tool won’t find any matches in the signature database. Only after the exploit has been observed in the wild will vendors update their signature lists and send out an update to customers, who then typically need to add the update.

Yes, protecting against the known vulnerabilities that many script kiddies will try is indeed valuable. However, the script kiddies don’t pose the same threat as a well-trained hacker or even a hacker who possesses knowledge of a zero day vulnerability. Without any protection against new or unseen attacks, signature-based tools leave a wide attack surface that needs to be accounted for another way.

Signatures Everywhere!

Many organizations use automated security scanners to find vulnerabilities in their apps, and in turn can update their WAFs with the information learned from the scanner. So if the scan finds vulnerability ABC, then the security rules for that vulnerability can be automatically for the WAF to import (this isn’t the case with every tool, but is a feature than many tools highlight). The problem is that the scanner is using heuristics to find the vulnerabilities in the first place. Herein lies the vicious circle of signature-based security and the illusion of security.


Vulnerability scan run with signature-based tool > Rules created from scan > Rules imported into security tool > New scan rules released, prompting rescan >


With this type of system in place, you’re never really achieving protection against anything other than known vulnerabilities. It’s like basing all flight security off of the do-not-fly list, but not knowing you can/should stop the person with a dangerous looking item for – at the least – a further inspection.

Another issue with this approach is the constant need to update the rules. Not only does your security depend on a rule existing, but it also depends on you updating the rules (unless rules update automatically) immediately upon release. A breach could come down to: no rules existing to stop an exploit, or you not updating the rules in a timely manner.

A different approach

There are alternative ways to approach web application security, and not all vendors are using a signature-based model. Port80 Software takes an algorithmic and behavioral-based approach that combines whitelists and blacklists and completely ditches the signature model.

The signature approach is so common that when people come to evaluate our Web application firewall, ServerDefender, they often are confused by its non-use of signatures. People often ask, “Well, if it doesn’t use signatures, then how is it providing protection?” and “How often do you update signatures? And are they free?”

There are indeed alternative ways to approach web application security, and not all vendors are using a signature-based model. Port80 Software takes an algorithmic and behavioral-based approach that combines whitelists and blacklists and completely ditches the signature model.

Curious to see what our approach is? Learn about our innovative – signature-free – approach to application security.

No Comments »

Leave a Reply