Application servers, such as IBM's WebSphere Application Server (WAS) and Apache's Tomcat, are just a few examples of technologies that support and promote the exchange of data in today's ever-so-popular, multi-tiered client/server model. Chances are, if your business employs any such technologies, you also (or at least you should!) perform data validation on your clients' input, but are you doing so safely and securely? This article describes a solution and provides an example that illustrates the concept of server-side data validation and how it guarantees that a client hasn't manipulated the data in a destructive manner.
Understanding the Problem
In today's complex world of computing, Web pages that solicit a user's input are a dime a dozen. This type of behavior is exhibited everywhere: from visiting an e-commerce Web site and entering order information (e.g., name, shipping address, quantity, etc.) to posting a message on your favorite Web forum. In all of these cases, there exists a common required step: HTML form validation. This step, especially for e-commerce Web sites, is crucial in terms of application security and data integrity. Thus, it is imperative that all preventative measures are taken to ensure a user's input is valid in the context of your application. That said, if sufficient validation measures are not taken, a user could submit altered and/or corrupted data for processing, potentially leaving your business application in a state of disarray.
Common Mistakes
There are two relatively common mistakes when performing form validation, both of which are discussed below.
Little or No Client-Side Form Validation
Believe it or not, there are instances in which some Web programmers do not even bother validating a user's input. That is, arbitrary data that a user sends to the server is blindly accepted. This obviously is a serious problem in that a user (malicious or not) could send data that either doesn't make sense in the application's context or is in some way harmful to the application's integrity. In other instances, some Web programmers ensure only that a form's values are filled in, which leaves the application vulnerable to the same effects. In each of these cases, it would not take much (i.e., "user skill") for a user to compromise the application's integrity and/or security.
Purely Client-Side Form Validation
Probably the most frequently employed form validation method is pure client-side form validation. This behavior is exhibited when code is executed directly on the client's machine to validate input. There are two good reasons to use client-side validation:
- It's a quick and easy validation mechanism; if the user's input is invalid, the alarm is immediately triggered upon unsuccessful submission of the form.
- It allows the programmer to safely display one error at a time and focus on the wrong field, ensuring that the user correctly fills in the required details.
Take for example the following JavaScript code fragment that illustrates client-side form validation, whose job is to ensure that the imaginary form's age field is correctly formatted:
function validateForm(form) {
if(parseInt(form.age.value) != form.age.value) {
alert('Please enter an age using numbers only.');
form.age.focus();
return false;
}
else if(parseInt(form.age.value) <= 0) {
alert('Please enter a positive age.');
form.age.focus();
return false;
}
else
return true;
}
To the bare eye, this looks great, right? The client received and validated its input and then happily continued processing. However, keep in mind that all of this code is executed on the client's machine. This could potentially allow a malicious client to completely subvert the validation logic and send, for example, a negative age value back to the server (which should have been prevented by the client-side validation). While in this particular instance, a negative age value is probably relatively harmless, the security and data integrity implications go much further in cases where more sensitive information is being solicited. While client-side validation is convenient and beneficial, it is certainly in need of a complementary mechanism.
The Solution
The suggested solution complements client-side form validation with server-side validation. As mentioned earlier, client-side validation can easily provide friendly reminders to non-malicious users that their input, for one reason or another, is not valid and should be corrected. This is also "friendly" for the programmer in that the client-side logic (e.g., a JavaScript validation mechanism) is relatively simple to implement within a few lines of code. However, relying solely on client-side form validation can leave your application prone to malicious users. Therefore, it is highly recommended that when the server (e.g., a PHP script, a Java servlet, a JavaServer Page, etc.) receives a user's input, it too (in addition to the client) performs data validation. Because input is also checked when it is received by the server, the scenario described above, in which the user can potentially subvert the programmer's client-side validation, is no longer a threat. The server will simply reject the invalid input.
Take for example the following PHP code fragment that illustrates server-side form validation, whose job is to ensure that the imaginary form's age field is correctly formatted:
function isValidAge() {
if(!isset($_REQUEST['age']))
return false;
// Is age an integer?
if(ereg("^[0-9]+$", $_REQUEST['age'])) {
$_REQUEST['age'] = (int) $_REQUEST['age'];
// Make sure age is positive
return ($_REQUEST['age'] > 0);
}
else
return false;
}
if(!isValidAge()) {
// Deny the request if it's deemed invalid
echo 'The age REQUEST argument has an invalid value!';
exit;
}
// The age parameter has now been validated; processing may
// now safely continue.
?>
Prior to the imaginary form's age value being processed, the server takes an extra moment to examine and validate the value of age, thus eliminating any possibility of the data being corrupted by a malicious client. It is important to understand that server-side form validation, unless used with other technologies, such as SSL, is not protected from networking attacks like the man-in-the-middle attack. Rather, it simply guarantees that the parameters that the server receives are still valid from the application's perspective.
Server-side form validation certainly adds some additional processing overhead (as form validation now has to be done in two locations—on both the client and the server) to the application's processing, but this is typically a relatively inexpensive operation, and it is absolutely necessary for a reliable and secure application. The other downside to using server-side validation is that it requires a little more effort from the programmer in terms of handling erroneous situations. Realistically speaking, the code fragment above, upon receiving an invalid age parameter, would push the user back to the Web page, repopulate the form with the user's valid fields, and highlight the problematic fields for immediate correction; this is obviously an additional chunk of work, especially if you're soliciting many inputs from the user. In any case, the additional effort is well worth it because invalid data will no longer be a concern.
Piecing the Puzzle Together
With such widespread use of client-server application models in existence today, especially those that are business-related, it is important to understand how to safely and securely validate your clients' input. The mechanism described in this article, that is, employing both client- and server-side data validation, will make your applications one step closer to being completely protected from malicious clients.
Joe Cropper is a Software Engineer at IBM in Rochester, Minnesota. Joe works as part of the IBM Customer Test team, and his areas of expertise include DB2/UDB 400, multi-tiered client-server technologies, and a variety of object-oriented programming languages. Joe can be reached via email at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online