Meaningless Drivel is fun!*
The moose likes JSF and the fly likes Clear the value of parameter 'javax.faces.ViewState' Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Clear the value of parameter Watch "Clear the value of parameter New topic
Author

Clear the value of parameter 'javax.faces.ViewState'

leo donahue
Ranch Hand

Joined: Apr 17, 2003
Posts: 327
How do I prevent someone from clearing the value of the ViewState parameter to my web form when it is submitted?

JSF 1.2 Mojarra and Tomcat 6.0.20

When the ViewState parameter is cleared, using a crafted URL instead of the form button, and the form is submitted, Tomcat 6.0.20 will output a "java.io.EOFException"

Is handling this exception in an error-page element the correct way to handle this? Or should I check for the ViewState value in my controller?

I read in the JSF 1-2 spec, section 7.6.2 that in client STATE_SAVING_METHOD, the state information must be included in the subsequent request. I am using a client STATE_SAVING_METHOD approach. Is this causing my problem?


Thanks, leo
leo donahue
Ranch Hand

Joined: Apr 17, 2003
Posts: 327
I'd like to re-phrase this question if possible.


How do I prevent someone from clearing the value of the ViewState parameter to my web form when it is submitted? by: leo donahue


I've come to the conclusion that I can't prevent someone from tampering with the POST URL and submitting my form without a ViewState parameter.

What I can do is use an actionListener with an 'immediate' atrribute that will check whether the ViewState parameter has a value. Calling renderResponse() will skip the rest of the life cycle, but is that what I want? Is there a better way to check for the existence of a ViewState value and terminate the request if the value is empty?

Something like this:


pseudo-code:

if(viewState==""){
return "navigation rule?" // I don't think actionListeners can navigate though
just render the response?
else {
call method that starts the web app
}
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16020
    
  20



In fact, that's one of my favorite ways to short-circuit webapps that had "clever" user-designed login systems and access stuff that they though they'd protected.

If you never trust ANYTHING that comes from a client, you'll have a much happier life.


Customer surveys are for companies who didn't pay proper attention to begin with.
leo donahue
Ranch Hand

Joined: Apr 17, 2003
Posts: 327
Never trust ANYTHING that comes from a client?

If I understand this correctly, not only do I need to test for a value for each of my components, but also the length of the value, whether there are html characters, etc?

How do you validate a view state value? j_id1:j_id3 That number increases with each client request. So what is considered valid?

My webapp contains a form, a text field, a submit button and a hidden viewstate field. Any one of these could have an empty value, or some other bizzare value.

What is the order of importance?

1. value exists?
2. value length is less than some number? I don't want someone trying to submit 3,000 chars for the value of one component.
3. value does not contain special chars?
4. If any of the above, terminate the session?

Why doesn't the JSF framework handle this? Especially for the viewState param, since the framework adds it to the page and knows how to increment that value.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16020
    
  20

This isn't a JSF thing, and I didn't really mean so much the infrastructure stuff, which (usually) only harms the client if they muck with it. What I mean by "don't trust:" is that if you send sensitive data out to the client and expect the client to send it back without any tampering, you'll get what you deserve.

Here's an example. Suppose you have a Shopping Cart. Rather than keep the cart information in a server-side session where only server logic can touch it, suppose you send out the unit prices in the cart page display and read them back again when the cart goes to checkout. Now suppose in your cart there's an IBM zSeries mainframe, unit price $30,000,000. On the client side, I go in and hack the cart form, changing the mainframe's unit price to the Everyday Low Savings price of $3.98 and submit it back for checkout.
leo donahue
Ranch Hand

Joined: Apr 17, 2003
Posts: 327
Tim, Thank you.

I understand the sensitive info point and the ability to change the values.

My webapp is a simple query page that is not bookmarkable. I'm trying to prevent the crash, Tomcat 6.0.20 from showing showing info messages, when someone blanks out my viewState parameters, and other component params.

IBM Rational App Scan indicates that when this happens, I'm allowing an information level error message that may allow users to see sensitive info, that info being the bean.methodname of the action attribute for the submit button. This tool, when it audits my site, clears out every component value and submits the page, then indicates that I have information level errors.



If someone submits my form without a viewstate param (vwstate==""), is the correct way to handle this type of request by terminating the session or calling renderResponse(), or calling responseComplete()?

I don't know that I can satisfy this audit tool with respect to this problem.

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16020
    
  20

Aha.

I've been less than impressed with how well IBM Rational products behave, especially considering the cost. But in this case, I think that the information is already printed on the OUTSIDE of the barn door, so anyone who wants to snoop doesn't even need to send back a request, malformed or otherwise.

In other words, unless my so-called memory is faulty, a simple "View Source" on the displayed web page should reveal the same info.

While it's true that the less you reveal, the better, this is about the same level of security exposure that you'd see in that any HTML FORM has a URL is revealing secrets about how it decodes URLs and what functions are URL-accessible (something that occasionally allows me to slip by DIY security systems). Balance that against the fact that this is a request/response server environment. You can't call these methods directly, they're called through several layers of indirection. In the case of JSF actions, there are no parameters passed directly to the action method, so it's hard to do a SQL-injection type attack. Nothing is bulletproof, but Sun doesn't certify its frameworks without very careful scrutiny of the possible security weaknesses, and in the case of JCP-designed systems, the board that vets the product in question consists of major players, often including IBM. Of course IBM is infamous for often acting like several different companies that don't particularly like each other, so there's nothing remarkable when one division of IBM makes assertions that another division of IBM may not agree with.

Since the whole point of paying absurd sums of money to IBM is that IBM is famous for its service (even if you do often get it in Bombay Welsh these days). So before panicking, I recommend contacting them and asking what methods (assuming any) that they recommend for mitigating this alleged security weakness. Bear in mind that the product is probably intended to vet non-JSF sites where this sort of exploit could happen in a less secure context.

You might also want to investigate Sun's official JSF support facilities.

I admit to not being especially evil or devious, but I can't think of any obvious way to exploit knowing bean/method names unless the app was already cracked into by more heinous means (and maybe not then). And, like I said, this stuff gets a pretty thorough going-over. So I'm not especially worried.

I/we would like to hear what you might uncover on the topic, though.
leo donahue
Ranch Hand

Joined: Apr 17, 2003
Posts: 327
IBM Rational App Scan produces a Full Security Report and highlights many remediation tasks, which do not effect my webapp, except the viewState issue.

I changed some of the names to protect the innocent.

Our office is required to respond to this security finding and provide the method by which we secure this one, and only one, issue. I'm at a loss to explain how to respond to something like this.

Detailed Security Issues
Vulnerable URL: http://our_webapp_url
Total of 1 security issues in this URL
[1 of 1] Application Error
Severity: Informational
Test Type: Application
Vulnerable URL: http://our_webapp_url(Parameter =
javax.faces.ViewState)
Remediation Tasks: Verify that parameter values are in their expected ranges and types. Do not
output debugging error messages and exceptions
Variant 1 of 32 [ID=6354]
The following changes were applied to the original request:
• Cleared the value of parameter 'javax.faces.ViewState'
Request/Response:
POST /servletname/page.jsf HTTP/1.0
Cookie: JSESSIONID=48D67286666F041A8E62E487B7340132
Content-Length: 107
Accept: */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)
Host: some_county.gov
Content-Type: application/x-www-form-urlencoded
Referer: http://our_domain/servletname/
searchForm=searchForm&searchForm%3Aj_id_jsp_1268966177_2=on&searchForm%
3AtxtAPN=1234&javax.faces.ViewState=
HTTP/1.1 500 Internal Server Error
Content-Length: 2230
Date: Thu, 07 Jan 2010 20:03:36 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Type: text/html;charset=utf-8
Connection: close
Age: 0

Remediation Tasks
Addressed Remediation Tasks Addressed Security Issues
http://our_webapp_url
Verify that parameter values are in their
expected ranges and types. Do not output
debugging error messages and exceptions
(Low)
Parameter: javax.faces.ViewState
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16020
    
  20

OK. As I read this, it isn't really a "ViewState" issue, it's that you aren't supposed to be emitting ANY internal debugging information back to the client, and that's a policy I heartily agree with. The user generally won't understand a stacktrace, it's an ugly display, there's not much the user can do with the information besides pass it back to the developers (who should have already logged it). And, it's true. A stacktrace does indicate information about the internals of a system. Although in the case of ViewState, the failure is likely to occur before any actual application code is encountered.

The solution to that is to set up an error intercept page in your web.xml file to catch FacesException and display a simple "Invalid request to server" message page. That should do what you need.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Clear the value of parameter 'javax.faces.ViewState'