Re: [Catalyst] Re: CSRF
On Sep 30, 2008, at 11:13 PM, Aristotle Pagaltzis wrote:
* Ashley [EMAIL PROTECTED] [2008-09-30 19:30]:
If scripting is involved that makes it a XSS attack instead,
though. No?
No.
Yeah, that was unclear. I was talking about our own sites
and Cat apps, not the web at large. It was in that context
which I suggested script based attacks were by definition
going to be XSS. Malicious ActionScript is still script.
But I hadn't read the POST exploits as described in the
white paper so I was wrong.
Might be pretty simple in Cat stuff. The crux of the POST
issue seems that the target site's cookies are still safe
from the attacking site's POST. So, off the top of my
head, untested, please modify, correct, refine, put
in wiki, etc.
Form template:
form action=[% c.request.uri() %] method=post
[% USE Digest.SHA1 -%]
input type=hidden value=csrf_check value=[% c.sessionid |
sha1_hex %] /
/form
Controller form validation:
use Digest::SHA1 qw(sha1_hex);
some_error_or_other() unless
$c-user_exists
and
$c-request-body_params-{csrf_check} eq sha1_hex($c-sessionid);
-Ashley
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: CSRF
Nope. On Sep 30, 2008, at 11:57 PM, Ashley wrote: Might be pretty simple in Cat stuff. The crux of the POST issue seems that the target site's cookies are still safe from the attacking site's POST. ... Form template: form action=[% c.request.uri() %] method=post [% USE Digest.SHA1 -%] input type=hidden value=csrf_check value=[% c.sessionid | sha1_hex %] / /form This won't work because the attacker can grab it by a GET and while it doesn't expose the sessionid, it does remain constant for the life of the session. As the white paper suggests, it has to be pseudo-random and it looks like it has to be per request. If no one else fields this in the next couple of days I'll come back to it and post a real solution. -Ashley ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: CSRF
Am 01.10.2008 um 08:57 schrieb Ashley:
On Sep 30, 2008, at 11:13 PM, Aristotle Pagaltzis wrote:
* Ashley [EMAIL PROTECTED] [2008-09-30 19:30]:
If scripting is involved that makes it a XSS attack instead,
though. No?
No.
Yeah, that was unclear. I was talking about our own sites
and Cat apps, not the web at large. It was in that context
which I suggested script based attacks were by definition
going to be XSS. Malicious ActionScript is still script.
But I hadn't read the POST exploits as described in the
white paper so I was wrong.
Might be pretty simple in Cat stuff. The crux of the POST
issue seems that the target site's cookies are still safe
from the attacking site's POST. So, off the top of my
head, untested, please modify, correct, refine, put
in wiki, etc.
Form template:
form action=[% c.request.uri() %] method=post
[% USE Digest.SHA1 -%]
input type=hidden value=csrf_check value=[% c.sessionid |
sha1_hex %] /
/form
Controller form validation:
use Digest::SHA1 qw(sha1_hex);
some_error_or_other() unless
$c-user_exists
and
$c-request-body_params-{csrf_check} eq sha1_hex($c-sessionid);
I think this gives you a good protection. But if you have a
XSS problem with your website the attacker could receive the
session cookie via XSS (see the facebook example above).
After that he can set up his form using the checksum.
The best way is to include a random string which has to be stored
somewhere for comparison on the server side.
moritz
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: CSRF
On Wed, Oct 1, 2008 at 12:19 AM, Ashley [EMAIL PROTECTED] wrote: Form template: form action=[% c.request.uri() %] method=post [% USE Digest.SHA1 -%] input type=hidden value=csrf_check value=[% c.sessionid | sha1_hex %] / /form On my personal site I do similar to this, but using jQuery to automatically add these to all forms and A links with class=requires-token. http://subtech.g.hatena.ne.jp/miyagawa/20080918/1221728765 Was talking about making Catalyst action to validate this token value as an action plugin, possibly in combination with jshirley's REST actions. This won't work because the attacker can grab it by a GET Usually not. The only chance where your browser leaks these csrf_check values would be when your app is vulnerable to CSSXSS (very rare and IE specific) or when you have crossdomain.xml that allows everything to be accessible from flash scripts. http://www.arunranga.com/articles/browser-cross-site.html#Flash and while it doesn't expose the sessionid, it does remain constant for the life of the session. As the white paper suggests, it has to be pseudo-random and it looks like it has to be per request. I agree on that it gives you a stronger security if the token is per-request instead of per-session but that's a trade-off. For instance per-request token breaks back-button-and-resubmit. Might be good if your site is a banking site and you don't want to duplicate the money transfers by back buttons, but that might not be the case if your site is more casual web 2.0 and does lots of XHR stuff with the same token etc. That said, Catalyst::Controller::RequestToken implements the per-request token and CSRF validation. http://search.cpan.org/~hide/Catalyst-Controller-RequestToken-0.01/ -- Tatsuhiko Miyagawa ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: CSRF
Am 01.10.2008 um 12:20 schrieb Aristotle Pagaltzis: * Moritz Onken [EMAIL PROTECTED] [2008-10-01 09:25]: The best way is to include a random string which has to be stored somewhere for comparison on the server side. Doesn’t have to be stored. Send a random string as well as a HMAC digest of a server secret plus the same string. To check a token, check if the random string plus server secret hash to the same digest as the one provided by the client. Since the server secret is not known or knowable to third parties, if the digest checks out, then this token must have been minted by the server. Very simple; near-zero CPU overhead; no server-side storage required. Hi, but this does still rely on the fact that there is no XSS issue on your page, doesn't it? I imagine a case where the attacker's site opens a iframe to your site which exploits a XSS issue and can send the hole form information back to the attacker's site. He has now the HMAC and the random string. cheers, moritz ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: CSRF
* On Wed, Oct 01 2008, Moritz Onken wrote: I imagine a case where the attacker's site opens a iframe to your site which exploits a XSS issue and can send the hole form information back to the attacker's site. He has now the HMAC and the random string. I was under the impression that you could open an iframe to someone else's site and manipulate it from javascript running on your own site, without relying on any vulnerabilities on that site. Maybe not? Maybe flash can do this? (Why do we even have iframes? For serving ads?) Anyway, Template::Refine is a great module for adding stuff to forms, in the event that your form builder isn't already adding some sort of unique token. I actually use it to add the name field to all the inputs; at some point I will just encrypt these like Seaside and many other frameworks do. You can then validate these with an ActionClass. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: CSRF
Am 01.10.2008 um 14:20 schrieb Jonathan Rockway: * On Wed, Oct 01 2008, Moritz Onken wrote: I imagine a case where the attacker's site opens a iframe to your site which exploits a XSS issue and can send the hole form information back to the attacker's site. He has now the HMAC and the random string. I was under the impression that you could open an iframe to someone else's site and manipulate it from javascript running on your own site, without relying on any vulnerabilities on that site. Maybe not? Maybe flash can do this? (Why do we even have iframes? For serving ads?) Hi Jonathan, you cannot access data on a different frame via javascript if it's not from the same server. This is called the same origin policy and is also applicable to iframes. greetings moritz ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: CSRF
Am 01.10.2008 um 16:23 schrieb Aristotle Pagaltzis: * Moritz Onken [EMAIL PROTECTED] [2008-10-01 12:55]: but this does still rely on the fact that there is no XSS issue on your page, doesn't it? So what? If your site has an XSS hole, it’s already game over. The attacker can inject Javascript that passes the same-origin policy blockade, so they can already do whatever the hell they want. I imagine a case where the attacker's site opens a iframe to your site which exploits a XSS issue and can send the hole form information back to the attacker's site. He has now the HMAC and the random string. Using an XSS hole to initiate a CSRF attack is like breaking in through the window to steal the house keys so you can unlock the front door. Attackers don’t build Rube Goldberg contraptions. Regards, Yeah you're right. Good point ;-) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: CSRF (plus session security)
On Wed, Oct 01, 2008 at 12:20:04PM +0200, Aristotle Pagaltzis wrote: * Moritz Onken [EMAIL PROTECTED] [2008-10-01 09:25]: The best way is to include a random string which has to be stored somewhere for comparison on the server side. Doesn’t have to be stored. Send a random string as well as a HMAC digest of a server secret plus the same string. To check a token, check if the random string plus server secret hash to the same digest as the one provided by the client. Since the server secret is not known or knowable to third parties, if the digest checks out, then this token must have been minted by the server. Very simple; near-zero CPU overhead; no server-side storage required. Ya, but it's valid for multiple posts. That might be ok, but in general, I only want one post for every one form generation (and no post without a form being generated). So, my forms all have a unique token that can only be used once. If used a second time I redisplay the form pre-filled with their post and ask them to submit again if that's what they really intended. That has the benefit of catching if the form is no longer valid (due to changes in the database from the first post). Of course, that doesn't prevent using two browser windows, etc. but it helps. Let me ask a related question: Where on the risk spectrum is CSRF compared to, say, session hijacking? I have an application that went from having some pages SSL encrypted to all pages encrypted for logged in users. I would like to only use secure cookies, but I place things in the session that I need for both SSL and non-SSL pages (an example is a language selection that is stored in the session).[1] Makes me think I need $c-session and also $c-secure_session as separate sessions and separate cookies. -- Bill Moseley [EMAIL PROTECTED] Sent from my iMutt ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
