javaee / mojarra

PLEASE NOTE: This project has moved to Eclipse Foundation and will be archived under the JavaEE GitHub Organization. After Feb. 1, 2021, the new location will be github.com/javaee/mojarra. Mojarra - Oracle's implementation of the JavaServer Faces specification
https://github.com/eclipse-ee4j/mojarra
Other
164 stars 58 forks source link

Implement client state timeout #616

Closed javaserverfaces closed 17 years ago

javaserverfaces commented 17 years ago
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.

Potential solution...

Encrypting client state still leaves applications vulnerable to the issue I described. 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 exception. 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 (http://www.theserverside.com/news/thread.tss?thread_id=46490#237621)

Environment

Operating System: All Platform: All

Affected Versions

[1.2_04]

javaserverfaces commented 17 years ago

Reported by @rlubke

javaserverfaces commented 17 years ago

@rlubke said: Cleaned up description.

javaserverfaces commented 17 years ago

@rlubke said: Created an attachment (id=523) Proposed Changes (ver 1)

javaserverfaces commented 17 years ago

@rlubke said: Fix checked in. Targeted for 1.2_05.

javaserverfaces commented 17 years ago

@rlubke said: reopening to set the proper owner.

javaserverfaces commented 17 years ago

@rlubke said: Assigned.

javaserverfaces commented 17 years ago

@rlubke said: Closing back out.

javaserverfaces commented 12 years ago

@manfredriem said: Closing issue out

javaserverfaces commented 17 years ago

File: changebundle.txt Attached By: @rlubke

javaserverfaces commented 17 years ago

Was assigned to rlubke

javaserverfaces commented 7 years ago

This issue was imported from java.net JIRA JAVASERVERFACES-612

javaserverfaces commented 17 years ago

Marked as fixed on Monday, September 24th 2007, 7:42:24 am