J2EE Architecture Best Practices (Continued)
Client-side validation is merely a convenience. It is performed to provide the user with quick feedbackto make the application appear responsive and give the illusion of a desktop application.
Server-side validation, on the other hand, is a must for building secure Web applications. It ensures that all data the client sends to the server is valid, no matter how the data was entered on the client side.
Thus, only server-side validation provides real application-level security. Many developers fall into the trap of a false sense of security by performing all data validation only on the client side. Here's a common example that illustrates the point:
A typical logon page has a textbox to enter a username and another textbox to enter a password. On the server side, one might encounter some code in the receiving servlet that constructs a SQL query of the form
"SELECT * FROM SecurityTable WHERE username = '" + form.getParameter("username") + "' AND password = '" + form.getParameter("password") + "';" and executes it. If the query comes back with a row in the result set, the user is successfully logged in. If not, the user is not logged in.
The first problem is the way the SQL is constructed, but let's ignore that for now. What if the user types in a username such as "Alice'--"? Assuming a user named "Alice" exists in SecurityTable, the user (or more appropriately the "hacker") successfully logs in. I'll leave finding out why this happens as an exercise for you.
Lesson 2: Security is Not an Add-On
As I mentioned in Lesson 1, I have had the privilege of examining many Web applications. A common theme I see is that all JavaServer Pages (JSP) pages have a layout similar to this pseudo-code:
User user =
if(user == null)
// redirect to
// the logon page…
// redirect to the
// "unauthorized" page…
code to display data and
allow user interaction -->
If the project uses an MVC framework such as Struts, all Action Beans have similar code as well. While ultimately this code works fine, it presents a maintenance nightmare if, for example, you find a bug or you must add a new role (such as "guest" or "admin").
Furthermore, all developers, no matter how junior, need to be familiar with this coding pattern. Sure, you can clean up JSP code with some JSP tags, and you can create a base Action Bean that cleans up the derived Action Beans. Even so, the maintenance nightmares still remain because the security-related code is spread out in multiple places. The Web application is also more likely to contain vulnerabilities because security is enforced at the application code level (by multiple developers) rather than at the architecture level.
More likely, the underlying problem is that security was slapped onto the project near the end. I recently worked as the architect on a project to be implemented in six releases over the course of more than a year, and security wasn't even mentioned until the fourth releaseeven though the project was exposing highly sensitive personal data over the Web. We engaged in a battle with the project sponsors and their management to change the release schedule to include all security-related functionality in Release 1 and move some of the "business" capability into subsequent releases. We ultimately won. We also have a happy client because it has an extremely secure application that protects its customers' private data, a fact in which it takes great pride.
Back to top