JSON users: Avoid CSRFs by not using top-level arrays • Hacker News Board

Re: JSON users: Avoid CSRFs by not using top-level arrays

#51

Post by sonnym » Sat, Jun 18, 2011, 7:27 PM UTC

zacharyvoase wrote: post #49

An idea: when using session-based authentication and returning JSON, check that the Referer [sic] matches your domain. I think I'm missing something major, though.

From http://www.codinghorror.com/blog/2008/09/cross-site-request-...

The HTTP referrer, or HTTP "referer" as it is now permanently misspelled, should always come from your own domain. You could reject any form posts from alien referrers. However, this is risky, as some corporate proxies strip the referrer from all HTTP requests as an anonymization feature. You would end up potentially blocking legitimate users. Furthermore, spoofing the referrer value is extremely easy. All in all, a waste of time. Don't even bother with referrer checks.

Re: JSON users: Avoid CSRFs by not using top-level arrays

#52

Post by sonnym » Sat, Jun 18, 2011, 7:32 PM UTC

espeed wrote: post #48

sonnym wrote: post #47

Earlier quoted context omitted.

My bad, I thought the timestamp was being inserted into a form ala Rails' authenticity_token method in a way that would allow it to go stale if a new request was submitted in a new tab. Although this makes sense, I feel it is not as safe as double submitting cookies, which effectively creates pseudo-random requests, but should still be safe enough in practice.

If you double submit on each request, this will double the number of requests on your server and reduce your server's capacity. And isn't all JavaScript subject to being subverted in XSS attacks, thus potentially rendering it ineffective?

In double cookie submission, you are not issuing two requests to the server, but rather using javascript to append the session id to either the post body or the URI.

Since the browser automatically submits the cookie via HTTP Headers, single submission by itself is not safe. Since a third party cannot read the value of the cookie, they cannot recreate the proper request and will, consequently, fail.

Of course, both our methods will fail under an XSS, but should still prevent CSRF. I still think a cryptographically generated secret stored in the cookie is less guessable than a timestamp.

Re: JSON users: Avoid CSRFs by not using top-level arrays

#53

Post by espeed » Sat, Jun 18, 2011, 7:47 PM UTC

sonnym wrote: post #52

espeed wrote: post #48

Earlier quoted context omitted.

If you double submit on each request, this will double the number of requests on your server and reduce your server's capacity. And isn't all JavaScript subject to being subverted in XSS attacks, thus potentially rendering it ineffective?

In double cookie submission, you are not issuing two requests to the server, but rather using javascript to append the session id to either the post body or the URI. Since the browser automatically submits the cookie via HTTP Headers, single submission by itself is not safe. Since a third party cannot read the value of the cookie, they cannot recreate the proper request and will, consequently, fail. Of course, both o…

The timestamp, session_id and user_id are tucked away in an AES encrypted bundle with a SHA-1 signature.

Re: JSON users: Avoid CSRFs by not using top-level arrays

#54

Post by the_mitsuhiko » Sat, Jun 18, 2011, 8:03 PM UTC

As the author of said document: The title here is misleading. While this attack is a form of CSRF, doing that does not magically solve all your CSRF problems. It just counters one particular attack vector which are JSON responses.

Re: JSON users: Avoid CSRFs by not using top-level arrays

#55

Post by thadeus_venture » Sat, Jun 18, 2011, 8:09 PM UTC

Why would this not work:

a) Resources using something other than GET are automatically not affected.

b) For GET resources, require that the body of the request contains a value, perhaps from a cookie but could be anything, ensuring that the request was made using xhr, which is domain restricted.

Sounds like the simplest way to me, curious why it wouldn't work.

Re: JSON users: Avoid CSRFs by not using top-level arrays

#56

Post by personalcompute » Sat, Jun 18, 2011, 8:09 PM UTC

tedunangst wrote: post #39

personalcompute wrote: post #21

Isn't this XSSI, not CSRF?

Apache Extended Server Side Includes? Haven't seen XSSI before. What's the I? I agree, this is not the attack I think of when somebody mentions CSRF. Well, the solution at least isn't. I would be very suspicious of anyone who claimed to solve their CSRF holes by not using arrays.

Cross Site Script Inclusion. The article touches on a lot of things (including CSRF), but the HN title refers specifically to JSON (As well as the link's '#' fragment identifier), and therefore the last section, where it shows an attack site including unprotected JSON through the tag, and unless I'm seriously mistaken, this is the definition of XSSI.

Re: JSON users: Avoid CSRFs by not using top-level arrays

#57

Post by the_mitsuhiko » Sat, Jun 18, 2011, 8:14 PM UTC

locci wrote: post #32

kkaefer wrote: post #25

Array() doesn't seem to be called when defining an array with [] in Chrome 12 and Firefox 3.6+

Because [] is not syntactic sugar for new Array. The code the article wrote about doesn't work in any implementation that I know of. I think the ESv3 spec wasn't very clear: "Create a new array as if by the expression new Array()." But the implementations (always?) did the right thing, and the ESv5 spec is more clear: it adds "where Array is the standard built-in constructor with that name."

> Because [] is not syntactic sugar for new Array

In Firefox 4 and other new browsers this is no longer the case. But right now it's still an issue as many people are using older browsers.

Re: JSON users: Avoid CSRFs by not using top-level arrays

#58

Post by personalcompute » Sat, Jun 18, 2011, 8:21 PM UTC

fmavituna wrote: post #38

Title is incorrect, Array usage is about Javascript/JSON Hijacking not protection against CSRF.

Correct, the technical term for it is 'XSSI', or Cross Site Script Inclusion.

Re: JSON users: Avoid CSRFs by not using top-level arrays

#59

Post by personalcompute » Sat, Jun 18, 2011, 8:26 PM UTC

sonnym wrote: post #51

zacharyvoase wrote: post #49

An idea: when using session-based authentication and returning JSON, check that the Referer [sic] matches your domain. I think I'm missing something major, though.

From http://www.codinghorror.com/blog/2008/09/cross-site-request-... The HTTP referrer, or HTTP "referer" as it is now permanently misspelled, should always come from your own domain. You could reject any form posts from alien referrers. However, this is risky, as some corporate proxies strip the referrer from all HTTP requests as an anonymization feature. You would end up potentially blocking legitimate users. Furth…

How is spoofing the referer extremely easy? I can think of no way for an attack site to do this, short of having control over the entire user machine (or a significant browser exploit anyways), at which point all of your webapp security is irrelevant.

Re: JSON users: Avoid CSRFs by not using top-level arrays

#60

Post by ww520 » Sat, Jun 18, 2011, 8:36 PM UTC

thadeus_venture wrote: post #55

Why would this not work: a) Resources using something other than GET are automatically not affected. b) For GET resources, require that the body of the request contains a value, perhaps from a cookie but could be anything, ensuring that the request was made using xhr, which is domain restricted. Sounds like the simplest way to me, curious why it wouldn't work.

Good thought. The "double-submitted cookie" technique does exactly that.