Hi Niels,
On 03/19/2010 09:47 PM, Niels Mayer wrote:
[i forgot to send this earlier]
Good point I missed. I would have to have a
script to disable such an
onerous 'feature' :)
I guess it will only work if a single number is valid basically forever. I
wish components had access to the
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?
You can't, but CSRF is *not* a replay attack. You are thinking about
way too involved attack scenarios and powerful attackers, try the simple
things first :)
Take a look here for example:
http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
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.
That is all nice, but slow down a bit, keep in mind that XWiki is not an
online banking platform or the like, signing and encrypting everything
would be an overkill here. There are several different (and more basic)
security problems around (XSS, CSRF, privilege escalation, ...), they
can't be fixed all at once.
Alex
Niels
http://nielsmayer.com
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs