Input Validation: Immunity Against Web Attacks
September 29, 2011
3 min read
By Arthur Hicken – Evangelist / Solutions Architect at Parasoft
Imagine for a second that you’re facing a deadly pandemic. You have two choices:
- Option A: Try to identify and treat every symptom that the disease might manifest itself as.
- Option B: Adopt a new health regimen that guarantees you will be completely immune to any infection.
The choice seems obvious here. Yet, many organizations are adopting the web security equivalent of “Option A” as they attempt to secure their sites in light of all the recent rash of hacker attacks (on web sites including Sega, Sony, PBS, US Senate, the CIA, FBI, and other government organizations).
A Rash of Injections
Most of these attacks have been classified as some flavor of injection attack: SQL Injection, Lizamoon mass injections, and other mesh injections that are reported to have already infiltrated over 30,000 sites. Considering that these attacks have already caused severe financial repercussions and marked embarrassment for the impacted organizations, it is not surprising that many security tool vendors are trying to market scanners as a low hanging fruit…and that so many organizations are reaching for this tempting option.
Regrettably, I’ve found that this approach is as precarious as it is common. There are a nearly infinite number of paths through even a simple web site. To rest assured that all those paths are impervious to attacks, you would need a tool to identify every possible path and then exhaustively test whether each path is free of all vulnerabilities that could be exploited to launch an attack (including attack variants that might not be recognized yet). This simply isn’t feasible. Even 100% source code coverage with a tool that scans for all the latest and greatest vulnerabilities is no guarantee that your organization’s web site won’t be the next victim of the current regime of “hactivists.”
Build Security Into Your Application
Rather than crossing your fingers and hoping for the best with this reactive “test vulnerabilities out” approach, try a proactive one that’s proven to prevent all current and future varieties of injection attacks: use input validation to build security in. Input validation involves ensuring that all of your input methods are wrapped in a validation method so that tainted user inputs cannot reach the application layer or database layer, which can be exploited to access information, alter content and control flow, or infect your partners and clients as part of a mass meshing scheme. When every input is properly validated immediately after it is received, you never need to worry about how, when, or where this user input is used.
How to do Input Validation
The input validation approach does require some work: it requires you to make certain changes to your code. Still, this is a relatively painless practice to adopt. If you make one small change—following naming conventions for validation methods—then you can automatically identify every instance of improper input validation that needs to be fixed.
Checking for input validation is typically accomplished by using rules-based static code analysis to identify any method invocation that returns dangerous data which are not passed as a parameter to validation method invocations, as well as to identify instances where tainted data is passed to the methods. If you enforce an input validation rule through rules-based static analysis—finding and fixing every instance where inputs are not properly validated—you can guarantee that injection attacks will not succeed. Attackers might try and try again, but by changing your code in the recommended manner, you will have essentially generated a deflector shield—preventing them from causing any damage no matter how the attack is launched.
Using Data Flow Static Analysis
If you also have data flow static analysis at your disposal, I suggest you use it as a means to check that your input validation process is being properly followed. If you’re being religious about validating every input, no issues should be reported here because it will be impossible for a path to lead to an injection. If for some reason the data flow analysis does uncover a potential path to an injection vulnerability, don’t just fix that specific problem and move on! Use this as an opportunity to improve your process. Figure out how that area of code evaded your input validation process, and what you can do to make the input validation process bulletproof from this point forward.
Download the Foundations of Secure Application Development eBook to learn why approaching security as a bug-finding exercise is risky and inefficient, and then explains how to make your web apps immune to attacks.
Image credit: Sarah G…