[Catalyst] Re: CSRF (plus session security)

2008-10-01 Thread Aristotle Pagaltzis
* Bill Moseley <[EMAIL PROTECTED]> [2008-10-01 20:45]:
> Where on the risk spectrum is CSRF compared to, say, session
> hijacking?

It’s even harder than XSS to pull off, and requires even closer
involvement of the attacker, but if they succeed, they can
overcome barriers that could prevent an XSS attack from doing
too much harm.

In a sense, it’s the next step in the progression from CSRF to
XSS. CSRF is dangerous primarily because of how easy it is to
set up an attack.

Regards,
-- 
Aristotle Pagaltzis // 

___
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/


[Catalyst] Re: fcgid

2008-10-01 Thread Aristotle Pagaltzis
* John Beppu <[EMAIL PROTECTED]> [2008-10-02 02:40]:
> Have any of you ::Engine::HTTP::Prefork users written init
> scripts for starting and stopping your Catalyst apps?

I must admit, not yet. The server I’m on is an RHEL5 VM – not my
choice, but I didn’t have another. Problem is, I couldn’t find
any guide for writing RHEL init scripts as solid as eg. the
Debian sysadmin guide, mostly just largely-cargoculted example
scripts that I would have to cargocult in turn. Maybe I’m just
dumb and/or blind, I dunno.

If anyone has a good reference resource, I would greatly
appreciate a pointer. I’ll publish the result too if there’s any
interest.

Regards,
-- 
Aristotle Pagaltzis // 

___
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] mix authentication stores

2008-10-01 Thread Matt S Trout
On Wed, Oct 01, 2008 at 04:58:51PM +0200, Jose Luis Martinez wrote:
> Tomas Doran escribió:
> 
> >Unfortunately, there is no such thing as an LDAP credential module on 
> >CPAN at the moment.
> >
> 
> Catalyst::Authentication::Credential::Authen::Simple should do the 
> trick. 
> http://search.cpan.org/~jlmartin/Catalyst-Authentication-Credential-Authen-Simple-0.02/lib/Catalyst/Authentication/Credential/Authen/Simple.pm
>  
> becasue Authen::Simple does support LDAP.

Fucking awesome.

This needs to be more widely publicised, do you think you could do doc
patches fr C::P::Authentication and a wiki write up? :)

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

___
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] Catalyst, DBIx::Class and Moose training in the UK

2008-10-01 Thread Matt S Trout
On Wed, Oct 01, 2008 at 08:48:33AM +0100, Dermot wrote:
> I would be interested. I would be nervous that I do not have the same
> level of skill or development exposure as some of the others. *Have I
> just voided my application*. We start an in-house project in the next
> month and I have recommended using Cat/Postgres so I want to get up to
> speed. I did enquiry with Mark Keating but he didn't get back to me.
> :-/

I think he might have been fighting VAT returns the past day or two so
he'll get back to you as soon as he has a minute.

If you re-send cc mst -at- shadowcat.co.uk I'll make sure he replies.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

___
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] Catalyst, DBIx::Class and Moose training in the UK

2008-10-01 Thread Matt S Trout
On Tue, Sep 30, 2008 at 12:37:22PM -0400, Carlos Arenas wrote:
> i am very much interested.
> 
> do you have pricing info available?  and what is the profile for
> attendees of both types of sessions?

I'll reply to this off-list tomorrow; I'm trying to keep discussion of
details off the mailing list since this isn't really a forum for me to
advertise shadowcat's services so I'm trying to make people aware we're
doing stuff while keeping traffic to a minimum :)

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

___
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: fcgid

2008-10-01 Thread John Beppu
On Wed, Oct 1, 2008 at 4:15 AM, Pedro Melo <[EMAIL PROTECTED]> wrote:

> Hi,
>
> On Sep 30, 2008, at 1:14 AM, Aristotle Pagaltzis wrote:
>
>  * John Lee <[EMAIL PROTECTED]<[EMAIL PROTECTED]>>
>> [2008-09-29 16:05]:
>>
>>> What's the general concensus in the catalyst community
>>> nowadays? Is mod_fastcgi preferred at large over mod_fcgid
>>> these days?
>>>
>>
>> Personally? ::Engine::HTTP::Prefork + ::Plugin::Static::Simple.
>>
>
> +1 for ::Engine::HTTP::Prefork.
>

Have any of you ::Engine::HTTP::Prefork users written init scripts for
starting and stopping your Catalyst apps?

--beppu
___
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)

2008-10-01 Thread Bill Moseley
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/


Re: [Catalyst] mix authentication stores

2008-10-01 Thread Jose Luis Martinez

Tomas Doran escribió:

Unfortunately, there is no such thing as an LDAP credential module on 
CPAN at the moment.




Catalyst::Authentication::Credential::Authen::Simple should do the 
trick. 
http://search.cpan.org/~jlmartin/Catalyst-Authentication-Credential-Authen-Simple-0.02/lib/Catalyst/Authentication/Credential/Authen/Simple.pm 
becasue Authen::Simple does support LDAP.



Regards,

Jose Luis Martinez
[EMAIL PROTECTED]

___
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

2008-10-01 Thread Moritz Onken


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/


[Catalyst] Re: CSRF

2008-10-01 Thread 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,
-- 
Aristotle Pagaltzis // 

___
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

2008-10-01 Thread Moritz Onken


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

2008-10-01 Thread 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?)

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: fcgid

2008-10-01 Thread Pedro Melo

Hi,

On Sep 30, 2008, at 1:14 AM, Aristotle Pagaltzis wrote:


* John Lee <[EMAIL PROTECTED]> [2008-09-29 16:05]:

What's the general concensus in the catalyst community
nowadays? Is mod_fastcgi preferred at large over mod_fcgid
these days?


Personally? ::Engine::HTTP::Prefork + ::Plugin::Static::Simple.


+1 for ::Engine::HTTP::Prefork.

I use both lighttpd and nginx as a front-end (all static content is  
served directly from them) and only dynamic requests reach the backend  
server.


I find the use of pure HTTP protocol (instead of fastcgi for example)  
a better compromise.


For the longest time (until I discovered ::Prefork) I used a minimal  
compilation of Apache+mod_perl that was very acceptable in terms of  
memory usage, but ::Prefork is much easier to install.


For complex configurations I like to have a perlbal in the mix. With  
it, and some custom plugin work, I was able to do live updates, where  
parts of your client base are each one running a different version of  
your app. You should not abuse this, but it is very good to slowly  
upgrade your user base to a new release. The trick I used was to  
switch the user (x % of them) on login to the new code-base.


Anyway, the use of HTTP allows me to do this kind of traffic  
engineering.


Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!



___
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

2008-10-01 Thread Moritz Onken


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/


[Catalyst] Re: CSRF

2008-10-01 Thread 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.

Instead of a random string, you can also use useful data: include
a datetimestamp of when you minted that token, and expire tokens
after X period of time.

Better still, include the form action URI in the token.

And the user ID.

Concatenate all these bits, then hash them together with the
server secret using HMAC, then concatenate the resulting hash.
Now you have a token that says “at $datetime, $user was granted
permission to POST to $uri, verifiable by $digest.”

Regards,
-- 
Aristotle Pagaltzis // 

___
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

2008-10-01 Thread Tatsuhiko Miyagawa
On Wed, Oct 1, 2008 at 12:19 AM, Ashley <[EMAIL PROTECTED]> wrote:
>> Form template:
>> 
>> [% USE Digest.SHA1 -%]
>>  
>> 

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] Catalyst::Plugin::UploadProgress

2008-10-01 Thread Ash Berlin


On 1 Oct 2008, at 08:41, Stephan Jennewein wrote:


On Wednesday 01 October 2008 03:25:42 am Tomas Doran wrote:

On 1 Oct 2008, at 01:44, Stephan Jennewein wrote:

On Wednesday 01 October 2008 12:39:08 am Andy Grundman wrote:

What Catalyst engine are you using?  What you described sounds like
the behavior with the default HTTP engine.  If that's what you're
using, try enabling fork mode with -f.


I'm trying fastcgi with lighttpd. Does it work with
fastcgi, do I have to use one thread (at the moment i'm using 5)?


No, the issue is that it doesn't work _unless_ you're using multiple
threads.

Can you replicate this behavior with myapp_server.pl -f, or does this
only happen for you with lighty?



Ups, my first mail didn't arrive,  myapp_server.pl --fork works  
fine. With

lighty the javascript stuff appears after pressing the button, but the
filesize is -1 and so you don't see any progressbar.

Stephan


Hmmm I wonder if thats because lightly is processing the upload to a  
temp file itself? I've seen references to a similar upload progress  
thing built into lighttpd, but that might only be in svn/1.5 versions...


-ash

___
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] Catalyst, DBIx::Class and Moose training in the UK

2008-10-01 Thread Dermot
2008/9/30 Carlos Arenas <[EMAIL PROTECTED]>:
> i am very much interested.
>
> do you have pricing info available?  and what is the profile for
> attendees of both types of sessions?
>
> ca.
>
> On Tue, Sep 30, 2008 at 10:39, Matt S Trout <[EMAIL PROTECTED]> wrote:
>> Shadowcat are looking to start offering training in Catalyst, DBIx::Class
>> and Moose usage, both introductory sessions and more advanced workshop-style
>> classes. The intended format would be two-day classes on site in Lancaster
>> (we'll either arrange accommodation or people can organise their own if
>> they prefer) with a maximum class size of about 10 to ensure there's plenty
>> of space for one on one time during exercises etc.
>>
>> Planned time frame for this is to have the first round of classes in Q12009.
>>
>> If anybody's interested in this, please send mail to mst -at- shadowcat.co.uk
>> (or just reply to this mail with comments)

I would be interested. I would be nervous that I do not have the same
level of skill or development exposure as some of the others. *Have I
just voided my application*. We start an in-house project in the next
month and I have recommended using Cat/Postgres so I want to get up to
speed. I did enquiry with Mark Keating but he didn't get back to me.
:-/

Dp.

___
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] Catalyst::Plugin::UploadProgress

2008-10-01 Thread Stephan Jennewein
On Wednesday 01 October 2008 03:25:42 am Tomas Doran wrote:
> On 1 Oct 2008, at 01:44, Stephan Jennewein wrote:
> > On Wednesday 01 October 2008 12:39:08 am Andy Grundman wrote:
> >> What Catalyst engine are you using?  What you described sounds like
> >> the behavior with the default HTTP engine.  If that's what you're
> >> using, try enabling fork mode with -f.
> >
> > I'm trying fastcgi with lighttpd. Does it work with
> > fastcgi, do I have to use one thread (at the moment i'm using 5)?
>
> No, the issue is that it doesn't work _unless_ you're using multiple
> threads.
>
> Can you replicate this behavior with myapp_server.pl -f, or does this
> only happen for you with lighty?
>

Ups, my first mail didn't arrive,  myapp_server.pl --fork works fine. With 
lighty the javascript stuff appears after pressing the button, but the 
filesize is -1 and so you don't see any progressbar.

Stephan

___
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

2008-10-01 Thread Moritz Onken


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:


[% USE Digest.SHA1 -%]
 



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

2008-10-01 Thread Ashley

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:

[% USE Digest.SHA1 -%]
  




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

2008-10-01 Thread 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:


[% USE Digest.SHA1 -%]
  



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/