Manage Learn to apply best practices and optimize your operations.

Fixing four Web 2.0 input validation security mistakes

Web app security expert Kevin Beaver uncovers common and uncommon Web application input validation problems and discusses solutions.

Kevin Beaver
Mistakes made in input validation can cause serious security weaknesses in Web applications, yet those mistakes can lie hidden until problems occur. In this tip, I share some input validation errors I've run across in my Web application security assessments.

The most interesting input validation issue I've discovered did not come up in one on my projects. I found it in a Web site on which I was storing a lot of my sensitive information. While perusing the site one day, I noticed that the unique identifier I used to log in with was contained in the URL. This is one of the most basic, yet dangerous, Web flaws around. I thought, "Surely, that's not what they're doing." I contacted the site admin and told her about it. She initially blew it off. She changed her tune when she told me her unique identifier on the system, and I named off her home address, the dates of birth and Social Security numbers of her children and other personal information. The phone went silent. She asked, "How'd you do that?!" I told her how simple it was and showed her how any user on the system could view anyone else's sensitive information by simply manipulating application input. She was dumbfounded, but she was grateful that we found this before it was exploited. Hopefully that was the case!

Moral of the story: Track user sessions and never allow the manipulation of input by simply changing a variable without re-authenticating the user. Better yet, don't place system variables in the URL at all.

On a related note, there are other URL-tampering issues I've come across that can turn ugly in a jiffy, such as being able to pipe local OS commands into the URL to obtain directory listings; download sensitive OS files, such as the UNIX/Linux passwd file; and perform URL/site redirection, via requests such as:


    You can imagine the outcome of these types of exploits. Not good for business!

    Moral of the story: Ensure that input, including URL parameters, is properly validated and filtered so the application only accepts what is expected.

    Another common Web input flaw I come across is related to contact forms. Unlike the weaknesses I've outlined, this doesn't create a threat to sensitive application-related information; but it can create a denial of service against the application, the server, and your email inbox. In probably nine out of 10 sites or applications I review, you can use an automated Web vulnerability scanner to flood contact forms with requests that usually sends thousands of bogus emails and fills up system log files to boot. Tha's something you probably don't want happening in your environment.

    Moral of the story: Filter or otherwise throttle form submissions. There are numerous ways to do this with session management, WAFs, and so on. In the interest of simplicity, this is something that's most easily resolved using CAPTCHA.

    Finally, no piece on input validation would be complete without covering cross-site scripting and SQL injection.

    Exploitable cross-site scripting flaws rely on forms not filtering input data. Hardly a Web security assessment project goes by without me uncovering a handful of pages that fail this test. Some flaws I see are code-related, while others require tweaks on the Web server side -- especially Apache. The essence is that in every situation I've been able to submit script code, have the application process it, and then see it reflected back to my browser. This is how cross-site scripting is exploited.

    SQL injection is similar in that SQL statements are injected into a form or URL, the server processes it and reflects the extracted data back to the user. The good news is that I rarely find directly-exploitable SQL injection vulnerabilities these days. The bad news is that SQL injection is often still present but the data is just not getting reflected back to the browser. Consider in a half-way SQL injection, but it's still an input validation issue nonetheless.

    Cross-site scripting and SQL injection are serious Web security flaws that can only be uncovered (at least realistically) by testing them with reliable Web vulnerability scanning tools. The fix is to code the application to only accept what is expected and nothing more. It sounds simple but can obviously be complex depending on your application. Either way, you've got to do it.

    About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC. He has over 20 years experience in the industry and specializes in performing independent information security assessments revolving around compliance and information risk management. Kevin has authored/co-authored seven books on information security including the ethical hacking books Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at

  • Dig Deeper on Software Security Test Best Practices

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.