[Catalyst] Re: CSRF
* Ashley [EMAIL PROTECTED] [2008-09-30 19:30]: If scripting is involved that makes it a XSS attack instead, though. No? No. XSS means injecting attacker-controlled HTML into a page. That’s usually used to inject Javascript, but doesn’t have to; just HTML could work just as well. The attack takes place when the victim visits a page on the vulnerable site and can cause anything to happen, including sending sensitive information from that page to third parties. CSRF means getting the victim’s browser to send a request to the vulnerable site. It makes use of what’s sometimes referred to as “ambient authentication,” ie. the victim is already logged into the vulnerable site, eg. with a remember-me-forever cookie, which the CSRF attack relies on to trigger actions that require authentication. The attack can take place anywhere on the web at all (you just have to get the victim to visit a site you control) but can only trigger functions of the vulnerable site. There is some overlap in what you can achieve with the two routes of attack, but the overall risk profiles are different. The main thing to keep in mind is that CSRF holes are much easier to exploit, by virtue of the fact that attacks can be initiated from any page on the web. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ 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 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] Catalyst, DBIx::Class and Moose training in the UK
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
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] 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/
[Catalyst] Re: CSRF
* 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 // http://plasmasturm.org/ ___ 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: fcgid
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
* 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/
[Catalyst] Re: CSRF
* 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 // http://plasmasturm.org/ ___ 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] mix authentication stores
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 (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/
Re: [Catalyst] Re: fcgid
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] Catalyst, DBIx::Class and Moose training in the UK
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] Catalyst, DBIx::Class and Moose training in the UK
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/
[Catalyst] Re: fcgid
* 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 // http://plasmasturm.org/ ___ 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 (plus session security)
* 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 // http://plasmasturm.org/ ___ 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/
