[Catalyst] Picking template type based on input
jon.mlist at gmail.com
Mon Mar 29 09:12:39 GMT 2010
On Mon, Mar 29, 2010 at 12:13 AM, Tomas Doran <bobtfish at bobtfish.net> wrote:
> On 28 Mar 2010, at 15:12, Jon mailinglists wrote:
>> I then login to my application in one tab, and in another tab access
>> this js/html. That will give back the data about me since I've got a
>> valid session which gets sent to my catalyst server. That means
>> evilempire.com has access to my logged in users data, and that's what
>> I want to protect them from. XSS from another site.
> Is that not XSRF, rather than XSS?
It seems like it is. I just stumbled upon this when checking out YUI
3, and had managed to stay oblivious to this problem before. I then
went on with checking if one could make an attack that way and got a
bit scared by the results and asked here. Classic case of reinventing
wheels. I called it XSS because I figured it was scripts running
across sites, but apparently this is XSRF as you said.
Thanks for the patience and decoding :)
>> That's why I was talking auth tokens or some other means of protection.
> A guess so, given that auth tokens are an XSRF protection really :)
>> I suppose more people have thought of that, and this isn't really
>> Catalyst specific but very general. What I wonder though is if there's
>> any built in mechanism to protect from that since if I haven't got it
>> all wrong are cookie based sessions pretty much useless as security.
> There are a number of pre-baked solutions to this on CPAN / in various form
> That said, there is no generic thing you can plug into an arbitrary Catalyst
> application which will try to protect you.
> It would be possible to parse the HTML your app output, add an extra hidden
> field to any forms you had generated in the page, and then look for a
> previously generated token and redirect / refuse the request if it wasn't
> However this would obviously not catch forms generated purely from
> its value in more complex applications. I can certainly remember the stuff
> which tries to achieve this that is baked into Rails making me scream :)
But if one has a header.tt2, and that header has an <input
be able to get that value and add it to each form generated. Wouldn't
that solve the problem, and also make sure that a request from a user
is really that and not coming from an evil site. Or is that a naive
With the risk of making you scream here:
Wouldn't it make sense to have and option in Authorization which
generates and stores a token server side, in either a database or in
the session (like Bill seems to do) at login time. If I'm not horribly
mistaken would one token be enough for a session since the attack is
blind and there's no way for a 3rd party to figure it out unless using
If that is correct, one can go about playing CRUD and allowing
/member/get_info?token=... and /member/set_info?token=... with GET
> That said - the wiki could very much benefit from a few pages which clearly
> explained the issue(s) surrounding XSS and XSRF in more detail, along with a
> rundown of what various form systems provide to mitigate these issues (and
> any other more generic modules available).
> Would you be prepared to write (even some) of this - given you seem to
> already be doing the research?
I just had a look and the wiki gives me an internal server error. I
can try to add some info regarding this, it might be better than
nothing but as I said, my English is far from perfect and it becomes
extra obvious when trying to explain something complex.
One thing I really think should be added there is a more verbose
explanation to the note in Catalyst::Manual::Tutorial::04_BasicCRUD:
Note: In practice you should never use a GET request to delete a
record -- always use POST for actions that will modify data. We are
doing it here for illustrative and simplicity purposes only.
Since this is potentially as nasty as storing untainted data in the
database, both for cases where GET is logical
(/get_really_private_data) and cases like this where one is
deleting/updating global data in a database.
>> Was this easier to follow?
> Yes. I thought that's what you meant the first time round, but I wasn't
> sure, and so I decided to wait for clarification (as other people had
> already replied when I saw your first mail).
Good, I'm trying to take a deep breath before explaining things but it
fails sometimes :)
More information about the Catalyst