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

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?

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

Take a look at the "sammy is my hero" worm, myspace sent a hash to the user like the one you propose, the worm made the required get request to get the hash, then made the post along with the hash. What prevents javascript from opening the page with the hash in an iframe and then reading in the iframe to get the hash, then creating a form with the required data and posting it to the save action? If we were to combine a requirement for post requests with checking of the referrer header, then we would block links, forms and javascript based attacks leaving only an attack through older versions of flash which support referrer forgery and at this point the difficulty of the attack becomes such that we need to consider a wider array of attack vectors.

Caleb Alex Busenius wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Sergiu Dumitriu wrote: I just did a few tests on iframes and I was wrong, they do have good same origin policy. Caleb _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Caleb, Caleb James DeLisle wrote: So the token is the same for consecutive (GET) requests coming from the same user? What happens if the user opens in edit mode two different pages? Isn't the second save invalidated by the first save?

Thanks, Marius _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On 03/16/2010 10:23 AM, Caleb James DeLisle wrote: What if this map would store a mapping (user + url) -> token,

or (user + reason) -> token, where "reason" would be some description of the intended change like "edit:Main.Test" or "rights:SomeUser+comment-edit"?

getToken would return different tokens for different pages/"reasons" and isTokenValid would need to provide the same url/"reason" for check to succeed. _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

This message seems to have disappeared, resending... Alex Busenius wrote: URL sounds like a good idea, what are the chances that a user will be editing the same page in 2 windows? Even if they are, editing the same page will cause past changes to be lost. Perhaps if the token fails they should get a page with a warning message and an opportunity to save anyway.

We can compare the URL to the referrer header which makes life easy (we would need access to the request but I think this is coming soon.)

This idea sounds like it would require a lot of extra infrastructure, maybe I am not seeing it right.

From the viewpoint of token component the exact content doesn't matter,

> > getToken would return different tokens for different pages/"reasons" and > isTokenValid would need to provide the same url/"reason" for check to > succeed. > > >> Caleb >> >>> Thanks, >>> Marius >>> >>>> If a configuration parameter is specified to disable the component, getToken returns "" and isTokenValid >>>> returns true. >>>> >>>> WDYT? >>>> >>>> Caleb >>>> >>>> >>>> Caleb James DeLisle wrote: >>>>> Sergiu Dumitriu wrote: >>>>>> On 03/10/2010 07:44 PM, Caleb James DeLisle wrote: >>>>>>> Take a look at the "sammy is my hero" worm, myspace sent a hash to the user like the one you propose, >>>>>>> the worm made the required get request to get the hash, then made the post along with the hash. >>>>>>> What prevents javascript from opening the page with the hash in an iframe and then reading in the iframe >>>>>>> to get the hash, then creating a form with the required data and posting it to the save action? >>>>>>> >>>>>>> If we were to combine a requirement for post requests with checking of the referrer header, then we >>>>>>> would block links, forms and javascript based attacks leaving only an attack through older versions >>>>>>> of flash which support referrer forgery and at this point the difficulty of the attack becomes such that >>>>>>> we need to consider a wider array of attack vectors. >>>>>> Sammy also required that XSS is enabled. >>>>>> >>>>>> Protecting from attacks originating in the wiki is kind of impossible at >>>>>> the moment, since JS can be inserted anywhere, and there's no (nice) way >>>>>> to prevent attacks from JS inside the application. As long as JS can be >>>>>> inserted, an attacker can do all the steps that the client would do to >>>>>> perform an action. >>>>>> >>>>>> The secret token works as a prevention mechanism when the attack comes >>>>>> from another site because the browser security model prevents the attack >>>>>> code to read the form. >>>>> I just did a few tests on iframes and I was wrong, they do have good same origin policy. >>>>> >>>>> Caleb >>>>> >>>>>>> Caleb >>>>>>> >>>>>>> >>>>>>> Alex Busenius wrote: >>>>>>>> Unfortunately, using POST requests instead of GET requests is not >>>>>>>> enough. It will not prevent attacks that use forms and/or JavaScript to >>>>>>>> generate POST requests. >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>> >>>>>>>> On 03/09/2010 02:48 PM, Caleb James DeLisle wrote: >>>>>>>>> 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 >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> devs mailing list >>>>>>>> devs(a)xwiki.org >>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>>>>>

Hi Alex, Alex Busenius wrote: Maybe we can return the user to the edit page with a _new_ token and the submitted content when the received token is invalid, asking the user for a confirmation and explaining her/him why the confirmation is needed. This way the user can retry saving the content (this step can repeat over and over if "she/he" keeps opening other tabs and saving the page there instead) or continue editing. Does this still prevent the attack?

Thanks, Marius _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

[i forgot to send this earlier] I guess it will only work if a single number is valid basically forever. I Request, Response and Session so it could expire on logout. Caleb Unless I'm misunderstanding, how can you protect against any form of replay attack if the token remains the same each time?

Protection against replay attacks is why such tokens are usually nonces or "one time pads". More practically, you can use a signed timestamp, in whatever form, e.g. my prior suggestion of crypto-cookes+SSL, or you can add an exrtra prop in core. Either way, both implementations time-out or cannot be reused much because the server encodes a timestamp, and encrypts&signs it with it's own secret key. While you're at it you can also have the server self-sign a bitmap of what privileges are available. On submission/post, only those privileges would be available to the executing code, due to the contents of the token/key/crypto-cookie's "privileges bitmap." The script would be executed in context of (1) validity of overall signature (2) valid signed and non expired timestamp (3) access granted in "privileges bitmap", e.g. programming rights, read-, and write-access to spaces (which can all be enumerated in a long string as bitmap). If the timestamp is expired, you could kick into a part of the app that checks that the user is logged in (in browser) through other means (hopefully uninstrusively) and then issues another token, with fresh timestamp as an automatic resubmission. By uninstrusive, I mean, you want the ticket to only be valid for a few seconds, but the user may take minutes, or hours to hit "submit" and shouldn't need to explicitly re-validate or re-auth with a user/password again (e.g. check for auth in cookie, client-certificate, etc). In any case, any time the server actually accepts a submission, it's because the timestamp on a short lived transaction was valid/signed. Anytime anything of "authority" needs to be performed, it checks the privileges bitmap to see if it was initially allowed-for, by the server, and by the valid code-stream (the one with access to the server key for signing/encrypting the bitmap)... That's a fair set of "checks and balances" against site-hacking.

Niels http://nielsmayer.com _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On 03/16/2010 09:33 AM, Caleb James DeLisle wrote: Did I understand the idea correctly that isTokenValid should be called from all macros that modify data, but not from the old core directly?

So for example the SaveAction (which saves edited documents at the moment) would not be protected for now, but the future action component would also use isTokenValid at some point? _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

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.

Digest access authentication is intended as a security trade-off; it is intended to replace unencrypted HTTP Basic access authentication which is extremely weak. However it is not intended to replace strong authentication protocols, such as Public key or Kerberos authentication.

In terms of security, there are several drawbacks with Digest access authentication:

Many of the security options in RFC2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy RFC2069 mode.

example, a MitM attacker could tell clients to use Basic access authentication or legacy RFC2069 Digest access authentication mode. To extend this further, Digest access authentication provides no mechanism for clients to verify the server's identity.

However, it is possible to instead store the digested value of the username, realm, and password.[1]

Alternative authentication protocols

Some strong authentication protocols for web based applications include:

Public key authentication (usually implemented with HTTPS / SSL client certificates).

IIS running configured for "Integrated Windows Authentication".

Weak cleartext protocols are also often in use:

Basic access authentication scheme

These weak cleartext protocols used together with HTTPS network encryption resolve many of the threats that Digest access authentication is designed to prevent.

Many of the security options in RFC2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy RFC2069 mode.

example, a MitM attacker could tell clients to use Basic access authentication or legacy RFC2069 Digest access authentication mode. To extend this further, Digest access authentication provides no mechanism for clients to verify the server's identity.