Whitelisting: Not just for Web Applications Anymore...

An interesting vulnerability was found this week in a prominent web app firewall. A user could append a pound sign (#) to the end of any URL and bypass all file type restrictions the firewall implements. This is yet another example of a fundamental problem in the computer industry: Using blacklisting (checking that the input doesn’t contain something bad) instead of whitelisting (checking that the input only contains what is good) for input validation. Blacklisting fails as soon as an attacker finds a new way to send malicious data that you are not looking for. Worse, there are a near infinite number of ways to send bad data. Whitelisting is more effective because you already know what the allowed characters or data types for an input are. Denying all input that isn’t allowed protects against all attacks regardless of whether they are known or unknown.

We’ve talked about this filtering problem before but it’s important to note that it exists all over software industry.  Another instance of the same carelessness in web apps took place in the IIS Unicode vulnerabilities, where characters such / and \ had Unicode equivalents that were not filtered by the app.  Therefore, one could craft a URL such as http://site_got_owned.com/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir to execute arbitrary commands.

            The filtering problem is also quite prominent in standard executable/binary applications as well.  IDS/IPS filters have problems with packet fragmentation and signatures that only catch one variation of an exploit.  Another problem occurs when the vendors of a vulnerable program only patch the execution path leading to the vulnerable code and not fixing the problem itself.

            Far too many products use and have used the practice of blacklisting. Not only is blacklisting less secure, it is also more resource intensive and far more prone to false positives that whitelisting.  The lesson here is that all applications, web or otherwise, must be secure by design and should not depend on any sort of firewalling or 3^rd party application to protect or sanitize or verify data for them.  SPI recommends integrating whitelisting directly into the application. The security of your organization may depend on it.