9 Mar
2010
9 Mar
'10
2:48 p.m.
I had thought about proposing this myself but decided against it because it seems
to me like a workaround for problems which can be solved in other ways.
Suppose we were to add a check to the actions which alter data which made sure the request
method
was 'post' and made it configurable in one of the configuration files? We would
have
to look over the default skins for incorrect links and leave the configuration
option off by default for backward compatibility at least until the next major version
but we could provide wiki operators the ability to prevent CSRF.
Caleb
Sergiu Dumitriu wrote:
On 03/08/2010 11:00 PM, Niels Mayer wrote:
Instead of having all these secret tokens and
modifying all over the place,
what about using something like realm-based-authentication (implemented in
cookies); the presence of one of these crypto-cookies performs the same role
as your nonce-token parameter. However, by having the verificartion of these
cookies integrated in with the overall login/access control mechanism of
Xwiki, you can achieve the same thing, without as many modifications and
incompatibilities (IMHO).
First, as Alex said, cookies are not an option since CrossSite requests
are valid, normal requests, and they will use the correct cookies.
Second, I already analyzed the possibility of using digest
authentication instead of basic (for WebDAV for example), and that's not
possible with XWiki, since it requires access to the plain text
password. With the current way that passwords are stored (as any object
property), it would be too unsafe to do that.
The use of realms allows for different levels of
security and access for
different components... e.g. one
might have public, private, and admin realms and different cookies would be
generated containing this
realm information (ie. what spaces can be accessed from any requests
associated w/ that cookie). The cookies are signed and timestamped and
therefore tamper-proof... You can generate these cookie-tokens as often as
you like, and they contain a signed timestamp that can allow you to set
quick expiry - on the order of one minute, or a few tens of seconds...
See http://www.frogdot.org/mod_auth_mda/mechanicg.html
http://www.frogdot.org/mod_auth_mda/mechanics.html
http://www.frogdot.org/mod_auth_mda/download.html
Niels
http://nielsmayer.com
On Sun, Mar 7, 2010 at 11:46 AM, Alex Busenius<the_unknown(a)gmx.net> wrote:
> Hi,
>
> I would like to add support for secret token verification to prevent
> CSRF attacks (see http://jira.xwiki.org/jira/browse/XWIKI-4873).
>
> The main idea is to add a random token as a parameter to each request
> that requires edit/comment/admin rights and check that this token is
> present on the server side. Since there are many ways one can modify
> documents, it would require many changes all over the place, in particular:
>
> * add a public method to XWikiContext:
> String getSecretToken()
> that generates a random token and caches it in the session
> * add a public method to XWikiRightService*:
> boolean isRequestLegitimate(String action, XWikiContext context)
> to check if the given action is allowed to be executed
> * add the following API methods to Context:
> String getSecretToken()
> boolean checkSecretToken()
> for including the secret token into forms/AJAX requests and checking
> that the current request is legitimate
> * add a new configuration parameter core.useSecretTokenValidation for
> disabling this functionality, and the corresponding method
> useSecretTokenValidation() to CoreConfiguration and
> DefaultCoreConfiguration
> * use the secret token (hidden input for forms or parameter of GET
> requests) in all templates (*.vm files in web/standard and skins,
> velocity macros in applications/**/resources/*.xml)
> * check the secret token in Save/Delete/Upload/etc.-Actions and throw
> an exception to deny the access if the check fails
> * check the secret token in all templates that directly modify data
> (e.g. web/standard/src/main/webapp/templates/admin.vm)
> * fix all selenium tests that directly modify pages using the
> open(...) method
> * make sure nothing else is broken
>
> WDYT?