[xwiki-devs] [vote] Integrate CSRF protection into XWiki 2.5
Hi devs, I've been working on a CSRF protection mechanism for quite some time. It is based on so called secret tokens (also called nonces) that are included into forms and links and checked on server side. The implementation allows to resubmit a failed request (e.g. in case the user is logged out in the meanwhile), so that the data is not lost in case of bugs. JIRA issue: http://jira.xwiki.org/jira/browse/XWIKI-4873 Component implementation: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-csrftoken/ Old proposal: http://lists.xwiki.org/pipermail/devs/2010-March/017727.html I think it is time to move the CSRF component to the main repository and start using it everywhere. The protection will be disabled by default until all bugs are fixed. The steps to do would be: 1. Move CSRF token component to platform 2. Fix all templates to use CSRF tokens 3. Fix all applications to use CSRF tokens 4. Fix all actions to check CSRF tokens 5. Fix all integration tests to work with enabled CSRF protection I have patches for steps 2-4, but NOT for 5. Many (about 30-40 last time I counted) integration tests still fail with enabled CSRF protection, because they (mis)use CSRF to set up tests (edit/create pages). Here is my +1 WDYT? Thanks, Alex
Hi, I'm +1 as well from a broad point of view since this will significantly improve XWiki's security and I know users who are waiting for this specific fix. However please consider it non-binding since I don't have a good grasp of the potential underlying implementation issues. Guillaume On Fri, Sep 10, 2010 at 01:54, Alex Busenius <[email protected]>wrote:
Hi devs,
I've been working on a CSRF protection mechanism for quite some time. It is based on so called secret tokens (also called nonces) that are included into forms and links and checked on server side. The implementation allows to resubmit a failed request (e.g. in case the user is logged out in the meanwhile), so that the data is not lost in case of bugs.
JIRA issue: http://jira.xwiki.org/jira/browse/XWIKI-4873 Component implementation: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-csrftoken/ Old proposal: http://lists.xwiki.org/pipermail/devs/2010-March/017727.html
I think it is time to move the CSRF component to the main repository and start using it everywhere. The protection will be disabled by default until all bugs are fixed.
The steps to do would be:
1. Move CSRF token component to platform 2. Fix all templates to use CSRF tokens 3. Fix all applications to use CSRF tokens 4. Fix all actions to check CSRF tokens 5. Fix all integration tests to work with enabled CSRF protection
I have patches for steps 2-4, but NOT for 5. Many (about 30-40 last time I counted) integration tests still fail with enabled CSRF protection, because they (mis)use CSRF to set up tests (edit/create pages).
Here is my +1
WDYT?
Thanks, Alex
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 09/10/2010 01:54 AM, Alex Busenius wrote:
Hi devs,
I've been working on a CSRF protection mechanism for quite some time. It is based on so called secret tokens (also called nonces) that are included into forms and links and checked on server side. The implementation allows to resubmit a failed request (e.g. in case the user is logged out in the meanwhile), so that the data is not lost in case of bugs.
JIRA issue: http://jira.xwiki.org/jira/browse/XWIKI-4873 Component implementation: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-csrftoken/ Old proposal: http://lists.xwiki.org/pipermail/devs/2010-March/017727.html
I think it is time to move the CSRF component to the main repository and start using it everywhere. The protection will be disabled by default until all bugs are fixed.
The steps to do would be:
1. Move CSRF token component to platform 2. Fix all templates to use CSRF tokens 3. Fix all applications to use CSRF tokens 4. Fix all actions to check CSRF tokens 5. Fix all integration tests to work with enabled CSRF protection
I have patches for steps 2-4, but NOT for 5. Many (about 30-40 last time I counted) integration tests still fail with enabled CSRF protection, because they (mis)use CSRF to set up tests (edit/create pages).
Here is my +1
+1, we'll fix tests as we go. Step 3 is very problematic, since "all" applications is not well defined. We can easily fix all the applications included in XE, we might fix some of the applications on code.xwiki.org, but we can't fix user code. So, we need very good documentation, big warnings in the release notes, etc. -- Sergiu Dumitriu http://purl.org/net/sergiu/
+1 for starting now. In the future we night consider adding a way for the application to request validation, that way some can be protected, others unprotected, but none broken. Caleb Sergiu Dumitriu wrote:
On 09/10/2010 01:54 AM, Alex Busenius wrote:
Hi devs,
I've been working on a CSRF protection mechanism for quite some time. It is based on so called secret tokens (also called nonces) that are included into forms and links and checked on server side. The implementation allows to resubmit a failed request (e.g. in case the user is logged out in the meanwhile), so that the data is not lost in case of bugs.
JIRA issue: http://jira.xwiki.org/jira/browse/XWIKI-4873 Component implementation: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-csrftoken/ Old proposal: http://lists.xwiki.org/pipermail/devs/2010-March/017727.html
I think it is time to move the CSRF component to the main repository and start using it everywhere. The protection will be disabled by default until all bugs are fixed.
The steps to do would be:
1. Move CSRF token component to platform 2. Fix all templates to use CSRF tokens 3. Fix all applications to use CSRF tokens 4. Fix all actions to check CSRF tokens 5. Fix all integration tests to work with enabled CSRF protection
I have patches for steps 2-4, but NOT for 5. Many (about 30-40 last time I counted) integration tests still fail with enabled CSRF protection, because they (mis)use CSRF to set up tests (edit/create pages).
Here is my +1
+1, we'll fix tests as we go.
Step 3 is very problematic, since "all" applications is not well defined. We can easily fix all the applications included in XE, we might fix some of the applications on code.xwiki.org, but we can't fix user code. So, we need very good documentation, big warnings in the release notes, etc.
+1 Thanks, Marius On 09/10/2010 02:54 AM, Alex Busenius wrote:
Hi devs,
I've been working on a CSRF protection mechanism for quite some time. It is based on so called secret tokens (also called nonces) that are included into forms and links and checked on server side. The implementation allows to resubmit a failed request (e.g. in case the user is logged out in the meanwhile), so that the data is not lost in case of bugs.
JIRA issue: http://jira.xwiki.org/jira/browse/XWIKI-4873 Component implementation: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-csrftoken/ Old proposal: http://lists.xwiki.org/pipermail/devs/2010-March/017727.html
I think it is time to move the CSRF component to the main repository and start using it everywhere. The protection will be disabled by default until all bugs are fixed.
The steps to do would be:
1. Move CSRF token component to platform 2. Fix all templates to use CSRF tokens 3. Fix all applications to use CSRF tokens 4. Fix all actions to check CSRF tokens 5. Fix all integration tests to work with enabled CSRF protection
I have patches for steps 2-4, but NOT for 5. Many (about 30-40 last time I counted) integration tests still fail with enabled CSRF protection, because they (mis)use CSRF to set up tests (edit/create pages).
Here is my +1
WDYT?
Thanks, Alex
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
3 +1 (+ 1 non-binding) 0 +0 0 -1 Will start doing it ASAP. Thanks, Alex On 09/10/2010 01:54 AM, Alex Busenius wrote:
Hi devs,
I've been working on a CSRF protection mechanism for quite some time. It is based on so called secret tokens (also called nonces) that are included into forms and links and checked on server side. The implementation allows to resubmit a failed request (e.g. in case the user is logged out in the meanwhile), so that the data is not lost in case of bugs.
JIRA issue: http://jira.xwiki.org/jira/browse/XWIKI-4873 Component implementation: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-csrftoken/ Old proposal: http://lists.xwiki.org/pipermail/devs/2010-March/017727.html
I think it is time to move the CSRF component to the main repository and start using it everywhere. The protection will be disabled by default until all bugs are fixed.
The steps to do would be:
1. Move CSRF token component to platform 2. Fix all templates to use CSRF tokens 3. Fix all applications to use CSRF tokens 4. Fix all actions to check CSRF tokens 5. Fix all integration tests to work with enabled CSRF protection
I have patches for steps 2-4, but NOT for 5. Many (about 30-40 last time I counted) integration tests still fail with enabled CSRF protection, because they (mis)use CSRF to set up tests (edit/create pages).
Here is my +1
WDYT?
Thanks, Alex
Hm, I can't count, 4 +1 and 1 non-binding :) On 09/14/2010 11:16 AM, Alex Busenius wrote:
3 +1 (+ 1 non-binding) 0 +0 0 -1 Will start doing it ASAP.
Thanks, Alex
On 09/10/2010 01:54 AM, Alex Busenius wrote:
Hi devs,
I've been working on a CSRF protection mechanism for quite some time. It is based on so called secret tokens (also called nonces) that are included into forms and links and checked on server side. The implementation allows to resubmit a failed request (e.g. in case the user is logged out in the meanwhile), so that the data is not lost in case of bugs.
JIRA issue: http://jira.xwiki.org/jira/browse/XWIKI-4873 Component implementation: http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-csrftoken/ Old proposal: http://lists.xwiki.org/pipermail/devs/2010-March/017727.html
I think it is time to move the CSRF component to the main repository and start using it everywhere. The protection will be disabled by default until all bugs are fixed.
The steps to do would be:
1. Move CSRF token component to platform 2. Fix all templates to use CSRF tokens 3. Fix all applications to use CSRF tokens 4. Fix all actions to check CSRF tokens 5. Fix all integration tests to work with enabled CSRF protection
I have patches for steps 2-4, but NOT for 5. Many (about 30-40 last time I counted) integration tests still fail with enabled CSRF protection, because they (mis)use CSRF to set up tests (edit/create pages).
Here is my +1
WDYT?
Thanks, Alex
participants (5)
-
Alex Busenius -
Caleb James DeLisle -
Guillaume Lerouge -
Marius Dumitru Florea -
Sergiu Dumitriu