Input Validation: Superfluous Most of the Time?
Do we actually need it for secure software?
Before I draw all the flashes of anger from all the software security-aware professionals out there, I insist you give some time to contemplate on the subtitle for some time.
Input validation is the heavily recommended technique in order to prevent malicious attacks against our software albeit from analyst and developer perspective it is sometimes treated as a burden. In this post, you can find a discussion over whether we can write secure code without using input validation whatsoever.
This is Bedirhan and I’ll present some solid examples that allows to ask that “obnoxious looking” question in a short while. However, to spice things up a little bit let’s first concentrate on web application firewalls (WAFs).
On Web Application Firewalls (WAFs)
For all who doesn’t know about it, WAF technology sits in front of your applications and thwart malicious attacks. While pretty useful, of course, they don’t solve the root causes of application related security bugs. What they succeed at is to patch buggy software.
WAFs act like filters and that filtering comes in two general flavors; blacklisting and whitelisting. Whitelisting is better applied than blacklisting because it accepts what is expected by the business owners and rejects the rest. WAFs usually can make use of both of the techniques.
Blacklists are usually open to bypasses, whereas, whitelists are sometimes not enough to make the software secure. While much better than blacklists, whitelists are not silver bullets.
Moreover, there’s a well known fact that there is a certain security vulnerability category that filtering can’t solve altogether; business logic problems. So, we have to implement logic in the WAF to mitigate logical/transaction based security weaknesses.
Anyways, let’s switch back to input validation done by the code itself. Although enforcing it closest to the source code prevents any impedance mismatch (different interpretation of input by the filtering component and the rest of the software), input validation most of the time is still far away from the root of the software security vulnerabilities.
As the name suggests, fixing the root cause requires the mitigation to be closest to the problematic area.
Well, let’s look at some of the vulnerabilities or vulnerability classes and their relative root cause protection measures. And check the relative weight that input validation has as the mitigation technique.
Vulnerabilities Better Solved w/o Input Validation
I won’t be able to list all the weakness classes exist today, however, here’s my take that includes a good deal of those which are critical. An exhaustive list could be prepared using MITRE’s CWE.
Don’t let the relatively short list fool you. It includes broad vulnerability categories such as Injection Vulnerabilities or Authentication or Authorization related weaknesses. For example, the category Injection Vulnerabilities comprises of vulnerabilities such as;
- Cross Site Scripting (XSS)
- OS Command Injection
- Hibernate Injection
- XML Injection
- SQL Injection
- LDAP Injection
- HTTP Response Splitting
- JSON Injection
- and many many more.
The best mitigation techniques for all injection type of vulnerabilities is contextual encoding or better yet parameter binding. It is not whitelisting. Because, contextual encoding or, if present, parameter binding is closer to the root cause, which is dynamic query/command formation.
As you can summon from the list, and I hope we agree on the mitigation techniques, the input validation takes up a little space. Perhaps less than 2 percent. So that means when we are aware of the internals of security problems, input validation doesn’t become the primary way of mitigation we apply to eradicate the root cause.
Counter Argument
I’m not, hopefully, that naive to claim that input validation is useless. On the contrary, I always try to encourage developers to use whitelisting input validation over blacklisting.
Having input validation around our application as close to outside boundary as possible is invaluable. In fact, here is the strategy (putting parameter binding aside since not all frameworks and APIs provide it) I advise whenever possible.
Here, whitelisting and encoding are used in tandem. The “funny” thing is when none of these techniques is applied systematically during the development phase, it becomes really hard to “fix” the problem later on. And for complex applications and busy teams, blacklisting almost always becomes the choice of securing the program. So, these cases with insecure decisions make us cough up whitelisting over encoding.
Nevertheless, as history repeats over and over again our current mitigation techniques, however strong as they seem to be, may not be adequate for the future attacks.
To stay safe against unknown malicious payloads we have to rely on whitelisting. It’s like a shield around our application. It has the possibility to fail, but, it’s better than having nothing.
Conclusion
There are a lot of hypes and trends in information security. Let’s don’t make whitelist input validation one of them. It’s one of the solid tools out there to secure our application.
However, there are better alternatives such as best practices, parameter binding, patching regularly, using secure alternatives etc. All of these mitigation techniques require an effort, which is usually the learning curve, however, we have to accept to take it as much as we can.
