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

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

#61

Post by mustpax » Sat, Jun 18, 2011, 8:42 PM UTC

alanning wrote: post #43

adolph wrote: post #6

I'm not familiar with CSRF so had to look this up: [Cross Site Request Forgery] vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action. The key to understanding CSRF attacks is to recognize that websites typically don't verify that a request came from an authorized user. Instead they verify only that the request…

Haacked has a step-by-step description of how this attack works: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-js... The Microsoft asp.net web stack avoids this by automatically wrapping json responses with an object "{d:...}". The comments describe this as only affecting FF2.0 although testing was informal. (You should, of course, still protect your services.)

That wouldn't work, you can override the Object constructor in JavaScript as well. You have to prepend something like `while(1);` to the JSON responses you're returning.

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

#62

Post by [deleted] » Sat, Jun 18, 2011, 9:04 PM UTC

adamt wrote: post #50

mmmm wrote: post #22

Earlier quoted context omitted.

Hi, why not? If the attacker can't get any information without sending a token with the request, what's there to worry about? I'm not very good with js so I might have misunderstood something. Thanks!

The Django "{% csrftoken %}" that you put into forms (and similar things in other frameworks), is used when posting form responses. It turns into a hidden form field ( ). This helps protects against someone creating a form on their own malicious site, that posts some data to yours. This attack mentioned in the OP is effectively completely different. It is off a GET request. Imagine you were running a social network s…

[deleted]

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

#63

Post by mmmm » Sat, Jun 18, 2011, 9:07 PM UTC

adamt wrote: post #50

mmmm wrote: post #22

Earlier quoted context omitted.

Hi, why not? If the attacker can't get any information without sending a token with the request, what's there to worry about? I'm not very good with js so I might have misunderstood something. Thanks!

The Django "{% csrftoken %}" that you put into forms (and similar things in other frameworks), is used when posting form responses. It turns into a hidden form field ( ). This helps protects against someone creating a form on their own malicious site, that posts some data to yours. This attack mentioned in the OP is effectively completely different. It is off a GET request. Imagine you were running a social network s…

Thanks a lot for the excellent explanation. I tend to do my Ajax requests with post just to get the token in. Is there a reason not doing so, like savings in bandwidth or something like that? Might that be a gain Facebook is trying to achieve?

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

#64

Post by sonnym » Sat, Jun 18, 2011, 9:15 PM UTC

personalcompute wrote: post #59

sonnym wrote: post #51

Earlier quoted context omitted.

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.

You cannot assume a request is coming from a browser.

curl --referer http://www.example.come http://www.example.com

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

#65

Post by personalcompute » Sat, Jun 18, 2011, 9:22 PM UTC

sonnym wrote: post #64

personalcompute wrote: post #59

Earlier quoted context omitted.

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.

You cannot assume a request is coming from a browser. curl --referer http://www.example.come http://www.example.com

Yes, but if the user wishes to avoid their own security like this, they can already do it a thousand other ways (and to no adverse affect, there is no opportunity for an attacker to exploit this, I don't know what you're getting at).

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

#66

Post by rachelbythebay » Sat, Jun 18, 2011, 9:42 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.

Point A sounds perfect to me. Why bother with GET at all?

For point B, I notice that I get an "x-requested-with: XMLHttpRequest" when doing ajax() from inside jQuery. I assume this is not there when someone SCRIPT SRCs something (why would it be?), so that may be useful to someone.

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

#67

Post by sonnym » Sat, Jun 18, 2011, 10:02 PM UTC

personalcompute wrote: post #65

sonnym wrote: post #64

Earlier quoted context omitted.

You cannot assume a request is coming from a browser. curl --referer http://www.example.come http://www.example.com

Yes, but if the user wishes to avoid their own security like this, they can already do it a thousand other ways (and to no adverse affect, there is no opportunity for an attacker to exploit this, I don't know what you're getting at).

I was merely pointing out how easy it is to fake, although you are correct a third party site could not do this.

Atwood's point is that checking the "referer" will both be unreliable and, more importantly, lead to false positives; there are better alternatives, namely, double submitting cookies as I have pointed out elsewhere with regard to this article.

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

#68

Post by personalcompute » Sat, Jun 18, 2011, 10:16 PM UTC

sonnym wrote: post #67

personalcompute wrote: post #65

Earlier quoted context omitted.

Yes, but if the user wishes to avoid their own security like this, they can already do it a thousand other ways (and to no adverse affect, there is no opportunity for an attacker to exploit this, I don't know what you're getting at).

I was merely pointing out how easy it is to fake, although you are correct a third party site could not do this. Atwood's point is that checking the "referer" will both be unreliable and, more importantly, lead to false positives; there are better alternatives, namely, double submitting cookies as I have pointed out elsewhere with regard to this article.

He's definitely correct about the false positives and that nonces and/or double submitted cookies are superior, I'm not arguing that, just the 'furthermore, spoofing is extremely easy,' which makes no sense there.

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

#69

Post by squeed » Sat, Jun 18, 2011, 10:27 PM UTC

mmmm wrote: post #63

adamt wrote: post #50

Earlier quoted context omitted.

The Django "{% csrftoken %}" that you put into forms (and similar things in other frameworks), is used when posting form responses. It turns into a hidden form field ( ). This helps protects against someone creating a form on their own malicious site, that posts some data to yours. This attack mentioned in the OP is effectively completely different. It is off a GET request. Imagine you were running a social network s…

Thanks a lot for the excellent explanation. I tend to do my Ajax requests with post just to get the token in. Is there a reason not doing so, like savings in bandwidth or something like that? Might that be a gain Facebook is trying to achieve?

Yours is a good solution, and effectively blocks the attack mentioned in this article. From a REST purity standpoint, it's "unclean" to require all API calls to be POSTS, but, hey, life is short.

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

#70

Post by alanning » Sat, Jun 18, 2011, 10:37 PM UTC

mustpax wrote: post #61

alanning wrote: post #43

Earlier quoted context omitted.

Haacked has a step-by-step description of how this attack works: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-js... The Microsoft asp.net web stack avoids this by automatically wrapping json responses with an object "{d:...}". The comments describe this as only affecting FF2.0 although testing was informal. (You should, of course, still protect your services.)

That wouldn't work, you can override the Object constructor in JavaScript as well. You have to prepend something like `while(1);` to the JSON responses you're returning.

I can see why you would think that but it does work because a script that just contains a JSON object is not a valid JavaScript file. The browser will give an error. Whereas a script that just contains a JSON array is valid.