[
https://issues.apache.org/jira/browse/WICKET-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620932#action_12620932
]
Igor Vaynberg commented on WICKET-1782:
---------------------------------------
yeah, hdiv guys already mentioned they break ajax support for apps that use
their filter, so (1) is definetely a no-go for us. we are going to go the (2)
route, i am thinking a simple sunjcecrypt and a [sessionid.uuid] key...
> Protection against CSRF (cross-site request forgery) attacks
> ------------------------------------------------------------
>
> Key: WICKET-1782
> URL: https://issues.apache.org/jira/browse/WICKET-1782
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Affects Versions: 1.3.4
> Reporter: Gorka Vicente
>
> Currently Wicket doesn't include a uniform and automatic solution against
> CRSF vulnerability or OWASP-A5 vulnerability [1].
> In order to solve CSRF is necessary to avoid static HTML and create dynamic
> or aleatory HTML per user.
> Two posible solutions:
> 1. Include a random token (aleatory parameter) to each url (link or form).
> The name and the value of this parameter can be the same per user or change
> per request (more secure but perform worse). It seems that can be implemented
> creating other implementation of IRequestCodingStrategy interface.
> 2. Encrypt all urls (links and form urls) using "Request Coding Strategy"
> strategy offered currently by wicket (CryptedUrlWebRequestCodingStrategy).
> Provide a security factory to use a different key per user or add some
> aleatory data to encrypted data (for example user jessionid). (SunJceCrypt,
> bundled in Wicket, is vulnerable to CSRF because obtained encrypted string is
> the same for all the users)
> [1] http://www.owasp.org/index.php/Top_10_2007-A5
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
