You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Gorka Vicente (JIRA)" <ji...@apache.org> on 2008/08/08 13:27:44 UTC

[jira] Created: (WICKET-1782) Protection against CSRF (cross-site request forgery) attacks

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.


[jira] Commented: (WICKET-1782) Protection against CSRF (cross-site request forgery) attacks

Posted by "Kent Tong (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633146#action_12633146 ] 

Kent Tong commented on WICKET-1782:
-----------------------------------

Is it enough to make sure the pagemap id (representing the window) is random? This way another window will be unable to forge the request.

> 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
>            Assignee: Igor Vaynberg
>             Fix For: 1.3.5, 1.4-M4
>
>
> 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.


[jira] Commented: (WICKET-1782) Protection against CSRF (cross-site request forgery) attacks

Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
    [ 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.


[jira] Commented: (WICKET-1782) Protection against CSRF (cross-site request forgery) attacks

Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620963#action_12620963 ] 

Igor Vaynberg commented on WICKET-1782:
---------------------------------------

in order to have csrf protection you have to create an httpsession...stateless apps are not secure because you need a mirror token on the server

> 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
>            Assignee: Igor Vaynberg
>
> 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.


[jira] Commented: (WICKET-1782) Protection against CSRF (cross-site request forgery) attacks

Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625459#action_12625459 ] 

Igor Vaynberg commented on WICKET-1782:
---------------------------------------

in the near future is all i can say. if you would like it to be released earlier start a thread on the mailing list

> 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
>            Assignee: Igor Vaynberg
>             Fix For: 1.3.5, 1.4-M4
>
>
> 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.


[jira] Commented: (WICKET-1782) Protection against CSRF (cross-site request forgery) attacks

Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620920#action_12620920 ] 

Johan Compagner commented on WICKET-1782:
-----------------------------------------

about 1: 
include a random token in each url that wicket generates?
is then only 1 token valid for 1 request?
That will not work for wicket. because of partial ajax updates of subsets of the pages then we have urls with token Y  and with token Y+1 one 1 page and both urls old and new onces have to work fine.


> 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.


[jira] Commented: (WICKET-1782) Protection against CSRF (cross-site request forgery) attacks

Posted by "Jörn Zaefferer (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624628#action_12624628 ] 

Jörn Zaefferer commented on WICKET-1782:
----------------------------------------

I found the commit on svnsearch (http://svnsearch.org/svnsearch/repos/ASF/search?logMessage=csrf). Any idea when 1.3.5 will be released? This looks like a much better solution then trying to build my own "secure" forms.

> 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
>            Assignee: Igor Vaynberg
>             Fix For: 1.3.5, 1.4-M4
>
>
> 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.


[jira] Commented: (WICKET-1782) Protection against CSRF (cross-site request forgery) attacks

Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/WICKET-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620937#action_12620937 ] 

Johan Compagner commented on WICKET-1782:
-----------------------------------------

do we have a jsessionid always?
stateless pages?

What to do if for example there is not session yet? Then the default key is just used?

> 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.


[jira] Assigned: (WICKET-1782) Protection against CSRF (cross-site request forgery) attacks

Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg reassigned WICKET-1782:
-------------------------------------

    Assignee: Igor Vaynberg

> 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
>            Assignee: Igor Vaynberg
>
> 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.


[jira] Resolved: (WICKET-1782) Protection against CSRF (cross-site request forgery) attacks

Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Igor Vaynberg resolved WICKET-1782.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 1.4-M4
                   1.3.5

the default crypt factory is now KeyInSessionSunJceCryptFactory which uses a randomly generated encryption key stored in httpsession.

> 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
>            Assignee: Igor Vaynberg
>             Fix For: 1.3.5, 1.4-M4
>
>
> 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.