When placed inside a form, this component will first assign a unique identifier to the browser using a cookie that lives until the end of the browser session. This is roughly the browser's private key. Then a unique token is generated using various pieces of information that comprise the form's signature. The token may or may not be bound to the session id, as indicated by the value of the requireSession attribute. The token value is stored in the hidden form field named javax.faces.FormSignature.
There is an assumption when using this component that the browser supports cookies. Cookies are the only universally available persistent mechanism that can give the browser an identifiable signature. It's important to know that the browser submitting the form is the same browser that is requesting the form.
During the decode process, the token is generated using the same algorithm that was used during rendering and compared with the value of the request parameter javax.faces.FormSignature. If the same token value can be produced, then the form submission is permitted. Otherwise, an {@link UnauthorizedCommandException} is thrown indicating the reason for thefailure.
The UIToken can be combined with client-side state saving or the "build before restore" strategy to unbind a POST from the session that created the view without sacrificing security. However, it's still the most secure to require the view state to be present in the session (JSF 1.2 server-side state saving).
Please note that this solution isn't a complete panacea. If your site is vulnerable to XSS or the connection to wire-tapping, then the unique browser identifier can be revealed and a request forged.
@author Dan Allen
|
|
|
|