Affects Version/s: 1.2_04
Fix Version/s: 1.2_05-b03
Operating System: All
I ran into an interesting security issue using JSF client-side state saving.
Suppose you have simple form with a couple of text fields and a command button.
Over time, you discover that link spammers are using your form to promote a
pharmacopeia of male enhancement drugs.
Being the vigorous Java developer that you are, you decide to add a security
component to your form, such as Seam's CAPTCHA implementation, to prevent the
advertisement of these superfluous medicines.
The link spammers are wily; they don't sit around hitting the submit button each
time they want your business. Rather, they have some automated tools that
schedule and submit an offline copy of your web page.
Now, what happens when the link spammers post an older version of your form,
i.e. a snapshot of the view before you added the security component?
If you used client-side state saving, the UI component tree was saved along with
the HTML, so the link spammer's form submission does not contain the recently
added security component!
The net result is that, due to client-side state saving, the spammer can now
bypass your CAPTCHA security component.
I would switch to server-side state saving for security purposes, but some
frameworks require client-side state saving.
Encrypting client state still leaves applications vulnerable to the issue I
Perhaps an effective solution would be to expire the view state somehow, eg. if
the HTTP session associated with the incoming state has expired, throw a servlet
I'm sure a date/time token could be added to the encoded view state to track
when the view was serialized.
Applications could control this via web.xml, for example by specifying the
maximum age of the view state before it is considered invalid by the server in
way that is similar to how browsers handle expired cookies and digital certificates.
Information obtained from Ian Hlavats on a TSS discussion