The importance of input validation

This article is an excerpt from the book Hacking for Dummies published by Wiley Publishing.

Web applications are notorious for taking practically any type of input, assuming that it's valid, and processing it further. Not validating input is one of the greatest mistakes that Web-application developers can make. This can lead to system crashes, malicious database manipulation, and even database corruption.

Input attacks

Several attacks can be run against a Web application that insert malformed data — often, too much at once — which can confuse, crash, or make the Web application divulge too much information to the attacker.

Buffer overflows
One of the most serious input attacks is a buffer overflow that specifically targets input fields in Web applications. For instance, a credit-reporting application may authenticate users before they're allowed to submit data or pull reports. The login form uses the following code to grab user IDs with a maximum input of 12 characters, as denoted by the maxsize variable:

<form name="Webauthenticate" action="www.your_Web_app.com/login.cgi"
method="POST">
...
<input type="text" name="inputname" maxsize="12">
...

A typical login session would be presented a valid login name of 12 characters or less. However, hackers can manipulate the login form to change the maxsize parameter to something huge, such as 100 or even 1,000. Then they can enter bogus data in the login field. What happens next is anyone's call — they may lock up the application, overwrite other data in memory, or crash the server.

Automated input
An automated-input attack is when a malicious hacker manipulates a URL and sends it back to the server, directing the Web application to add bogus data to the Web database, which can lead to various denial of service (DoS) conditions.

Suppose, for example, that you have a Web application that produces a form that users fill out to subscribe to a newsletter. The application automatically generates e-mail confirmations that new subscribers must respond to. When users receive their e-mail confirmations, they must click a link to confirm their subscription. Users can tinker with the hyperlink in the e-mail they received — possibly changing the username, e-mail address, or subscription status in the link — and send it back to the server hosting the application. If the Web server doesn't verify that the e-mail address or other account information being submitted has recently subscribed, the server will accept practically anyone's bogus information. The hacker can automate the attack and force the Web application to add thousands of invalid subscribers to its database. This can cause a DoS condition on the server or the server's network due to traffic overload, which can lead to other issues.

I don't necessarily recommend that you carry out this test in an uncontrolled fashion with an automated script you may write or download off the Internet. Instead, you may be better off carrying out this type of attack with an automated testing tool, such as WebInspect or, or one of its commercial equivalents, such as Sanctum's AppScan (www.sanctuminc.com).

Code injection
In a code-injection attack, hackers modify the URL in their Web browsers or even within the actual Web-page code before the information gets sent back to the server. For example, when you load your Web application from www.your_Web_app.com, it modifies the URL field in the Web browser to something similar to the following:

http://www.your_Web_app.com/script.php?info_variable=X

Hackers, seeing this variable, can start entering different data into the info_variable field, changing X to something like one of the following lines:

http:// www.your_Web_app.com/script.php?info_variable=Y



http:// www.your_Web_app.com/script.php?info_variable=123XYZ

The Web application may respond in a way that gives hackers more information — even if it just returns an error code — such as software version numbers and details on what the input should be. The invalid input may also cause the application or even the server itself to hang. Similar to the case study earlier in the chapter, hackers can use this information to determine more about the Web application and its inner workings, which can ultimately lead to a serious system compromise.

Code injection can also be carried out against back-end SQL databases — an attack known as SQL injection. Hackers insert rogue SQL statements to attempt to extract information from the SQL database that the Web application interacts with. Microsoft has a good Web site dedicated to Microsoft SQL Server security, including Slammer prevention and cleanup. Also check out the popular and effective Shadow Database Scanner.

Hidden field manipulation
Some Web applications embed hidden fields within Web pages to pass state information between the Web server and the browser. Hidden fields are represented in a Web form as <input type="hidden">. Due to poor coding practices, hidden fields often contain confidential information (such as product prices for an e-commerce site) that should be stored only in a back-end database. Users should not be able to see hidden fields — hence, the name — but the curious hacker can discover and exploit them with these steps:

1. Save the page to the local computer.
2. View the HTML source code.
   To see the source code in Internet Explorer, choose View.Source.
3. Change the information stored in these fields.
   For example, a hacker may change the price from $100 to $10.
4. Re-post the page back to the server.
   This allows the hacker to obtain ill-gotten gains, such as a lower price on a Web purchase.

Cross-site scripting
Cross-site scripting (XSS) is a well-known Web application vulnerability that occurs when a Web page displays user input — via JavaScript — that isn't properly validated. A hacker can take advantage of the absence of input filtering and cause a Web site to execute malicious code on any user's computer that views the page.

For example, an XSS attack can display the user ID and password login page from another rogue Web site. If users unknowingly enter their user IDs and passwords in the login page, the user IDs and passwords are entered into the hacker's Web server log file. Other malicious code can be sent to a victim's computer and run with the same security privileges as the Web browser or e-mail application that's viewing it on the system; the malicious code could provide a hacker with full read/write access to the entire hard drive!

A simple test shows whether your Web application is vulnerable to XSS. Look for any parts of the application that accept user input (such as a login field or search field), and enter the following JavaScript statement:

<script>alert('You have been scripted') </script>

If a window pops up that says You have been scripted, as shown in Figure 16-5, the application is vulnerable.

Countermeasures

Web application attacks & vulnerabilities Learn more about Web application attacks, vulnerabilities and countermeasures against them with these resources: * Hacking for Dummies -- Web applications * Input Validation Attacks -- Hacking Exposed Web Applications  *  One simple rule to make your Web apps more secure: Input validation

Web applications must filter incoming data. The applications must check and ensure that the data being entered fits within the parameters of what the application is expecting. If the data doesn't match, the application should generate an error and not permit the data to be entered. The first input validation of the form should be matched up with an input validation within the application to ensure that the input parameter meets the requirement.

Developers should know and implement these best practices:

• To reduce hidden-field vulnerabilities, Web applications should never present static values that the Web browser and the user don't need to see. Instead, this data should be implemented within the Web application on the server side and retrieved from a database only when needed.
• To minimize XSS vulnerabilities, the application should filter out <script> tags from the input fields.
• You can also disable JavaScript in the Web browser on the client side as an added security precaution.

Some secure software coding practices can eliminate all these issues from the get-go if they're made a critical part of the development process.

-------------------------------
About the author: Kevin Beaver, CISSP, is founder and principal consultant of Principle Logic LLC. He has more than 16 years of experience in IT and specializes in information security. Kevin is also the author of The Definitive Guide to Email Management and Security by Realtimepublishers.com and co-author of The Practical Guide to HIPAA Privacy and Security Compliance by Auerbach Publications.