[Catalyst] Picking template type based on input
moseley at hank.org
Mon Mar 29 15:22:58 GMT 2010
On Mon, Mar 29, 2010 at 2:12 AM, Jon mailinglists <jon.mlist at gmail.com>wrot=
> 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.
I think you are missing it still. It's not really XSRF.
These terms are a bit fuzzy and overloaded, but in general:
XSS is where an attacker places script on the attacked site. This is
accomplished by correctly not filtering user input. One example is a blog
site where the attacker places script on a common page that many others
view. Another approach is for the attacker to create a link to the site
When the script runs it can, for example, send the cookie to the attacker's
site and then the user can use that session id to gain access.
XSRF is (typically, AFAIK) where the attacker's site includes a tag that
generates a request to another site. Wikipedia is worth reading, and it
includes this example:
The attacker has to know (or hope) the person that is viewing the page with
the <img> has an account at bank.example and that they are logged in (or
have a "remember me" cookie).
Of course, the <img> does a GET request to the poorly-coded bank site and
incorrectly causes something to happen. This works because the browser will
send the cookie with the request.
site. And any data that javascrpt brings in will be available to the page
that is loading the script. This is expected. It's also expected that the
browser will send the site's cookie along with the request.
Your example seems like XSRF because the attacking site is requesting a
a request to another site. It's also similar because in both your example
and the XSRF example above, the site is doing something dumb.
The bank.example site is dumb because it's allowing a GET request to make a
gives private data away.
And that's why AJAX requests follow same-origin policy. It provides a way
to fetch data from a site, but only from the site that the browser is
(Sure, the attacking site could create a form (perhaps in a hidden iframe)
and POST that, but hopefully your bank will return an "Are you sure you want
to transfer your money to Mallory?" confirmation screen first.)
> 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.
> If that is correct, one can go about playing CRUD and allowing
> /member/get_info?token=3D... and /member/set_info?token=3D... with GET
First, don't set_info with a GET request. That just makes the XSRF easy.
Second, if this is to protect against your example that returns JSONP (and
thus leaks personal user info) then, the real solution is to not return
I think the tokens are a mixed bag. Yes, the tokens would help, but if you
have them on your URLs then you have to worry about bookmarking and link
leaking. The tokens I use help with POSTing forms, but for critical changes
I still add an "Are you sure?" page.
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Catalyst