[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-4007) Provide an <s:token> UI component to secure JSF forms against cross-site request forgery (XSRF)

Provide an <s:token> UI component to secure JSF forms against cross-site request forgery (XSRF) ----------------------------------------------------------------------------------------------- Key: JBSEAM-4007 URL: https://jira.jboss.org/jira/browse/JBSEAM-4007 Project: Seam Issue Type: Feature Request Components: JSF Controls Affects Versions: 2.1.1.GA Reporter: Dan Allen Fix For: 2.1.2.GA Attachments: JBSEAM-4007-concept.zip Introduce the UI component tag <s:token> to secure JSF form posts against cross-site request forgery (XSRF) attacks. Please note that if the solution below is implemented in JSF 2, then Seam does not need to provide a custom solution and this issue can be closed. However, we still need to implement something equivalent for Seam Remoting. The problem today is that when using client-side state saving, a form POST can be crafted (forged) to submit into a JSF application from an external site (cross-site). The serialized view is simply passed in the javax.faces.ViewState parameter. JSF will blindly recreate the view and process the request. Server-side state saving is equally insecure since all the forged POST has to do is provide the identifier of the view state on the server in the javax.faces.ViewState parameter. Actually, this is only a problem since JSF generates sequential identifiers per session in the form j_id + # of views in session. Server-side state saving becomes event more problematic in JSF 2.0 since Facelets' "build during restore" feature is enabled by default. In this case, the javax.faces.ViewState parameter isn't even required since JSF will recreate the view before processing the request. The <s:token> UI component will perform two steps. First, it will 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. The <s:token> tag is used inside of an <h:form> and generates a hidden form field named javax.faces.FormSignature. The form signature is calculated as follows: sha1( signature = viewId + "," + formClientId, salt = clientUid ) The developer can also choose to incorporate the session id into this hash for a more secure token (at the cost of binding it to the session) sha1( signature = viewId + "," + formClientId + "," + sessionId, salt = clientUid ) When the form is submitted, the hash is recreated and compared against the value of the javax.faces.FormSignature parameter.