[ Team LiB ] |
Storing Data in Hidden Form VariablesGiven what you already know about JSP, servlets, and HTML forms, you already have the ability to keep track of data between requests. You can store user data in hidden form variables. Although not the most elegant solution, many applications use form variables to store user data. The idea is that every time the user submits a form, the form contains some hidden variables that provide information about the user. These variables might be a login ID and password or the user's name. The big hassle with using form variables is that all your forms must preserve these hidden variables and continue to pass them around. The best way to illustrate this technique is with an example. Listing 12.1 shows a login form that calls a JSP to handle the login. Listing 12.1 Source Code for Login.html
The goal of this example is to preserve the username across multiple pages. The Login.jsp page will have the username because it's passed as a form variable from Login.html. Listing 12.2 shows Login.jsp. Notice that it inserts the username as a hidden form variable. Listing 12.2 Source Code for Login.jsp
Figure 12.1 shows the output from Login.jsp. Figure 12.1. A page can contain hidden form variables that the user can't see.The third part of this example is a servlet that receives the hidden form variable along with the user's color choice. Listing 12.3 shows the servlet. Listing 12.3 Source Code for ColorServlet.java
Trying Out These Examples
Security Concerns with Hidden VariablesOne of the reasons you don't see hidden variables used very often in commercial Web sites, especially e-commerce sites, is that they are inherently insecure. Suppose Login.jsp actually verified the username and password. You would then assume that the username passed to ColorServlet is valid. But there is nothing to stop someone from inserting a bogus username and even a bizarre color by passing it in the URL for the servlet. Figure 12.2 shows an example of how the system can be tricked by inserting a phony username and color into the URL. Figure 12.2. A malicious user can send phony values for hidden form variables.Changing a username is bad enough, but imagine what could happen if someone did this with a bank account or credit card number! Certainly this technique needs some work. You might get clever and choose a variable name that is far less obvious than username. Suppose, for example, that you changed the name of the hidden variable to xpq7564HHgk. Surely no one would guess the variable name! Unfortunately, all someone needs to do is ask the browser to display the source for the page, as shown in Figure 12.3. Figure 12.3. Because a user can view the source to a page, you can't safely hide anything in the page.Another big concern with hidden form variables is that the user might accidentally bookmark the secure information. When you use an HTTP GET method (by setting method="get" in your <form> tag) to submit a form, the form variables all appear in the URL and will be part of a bookmark if the user bookmarks the page. Even hidden form variables show up in the URL. Most of these concerns can be eliminated by using an HTTP POST instead of GET. You'll recall that a POST embeds variables in the body rather than in the URL. If you use hidden form variables, even storing a single value, make sure you use an HTTP POST to help secure your application. The hidden form variable approach seems to work fairly well except for one thing: the hidden variable itself. First of all, putting the hidden variable in every form is a hassle. Second, it requires the application to use only forms for accessing server-side pages. This presents quite a few problems. For example, if you use a hyperlink, there are no form variables to pass. You must either rewrite your hyperlinks to include all of the information that is included in your form or find a better alternative. That alternative is the session object. |
[ Team LiB ] |
No comments:
Post a Comment