Title is incorrect, Array usage is about Javascript/JSON Hijacking not protection against CSRF.
Yeah, the article got it right (CSRF was the previous section) but the submitter titled it wrong.
JSON users: Avoid CSRFs by not using top-level arrays
41–50 of 85 posts
Re: JSON users: Avoid CSRFs by not using top-level arrays
#42I'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…
A few days ago I asked, "Ask HN: Best Approaches to Prevent Session Hijacking?" ( http://news.ycombinator.com/item?id=2663293 ) and presented a technique I'm experimenting with that uses session timestamps as tokens to validate that each request is authentic and an attacker hasn't stolen the session key. It works by updating the token (timestamp) on the server and in the cookie on each request and they both have to m…
How do you mitigate problems with a user opening multiple tabs over a span of time, and attempting to submit the first one opened?
I believe the best practice is to provide the user's session id in their cookie and provide that with the requests via javascript or even at the time of page rendering. Since a third party (untrusted domain) cannot access information from your cookie, they also cannot form a valid request.
This method is called double submitting cookies.
See: https://secure.wikimedia.org/wikipedia/en/wiki/Cross-site_re...
Re: JSON users: Avoid CSRFs by not using top-level arrays
#43I'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.)
Re: JSON users: Avoid CSRFs by not using top-level arrays
#44Earlier quoted context omitted.
A few days ago I asked, "Ask HN: Best Approaches to Prevent Session Hijacking?" ( http://news.ycombinator.com/item?id=2663293 ) and presented a technique I'm experimenting with that uses session timestamps as tokens to validate that each request is authentic and an attacker hasn't stolen the session key. It works by updating the token (timestamp) on the server and in the cookie on each request and they both have to m…
How do you mitigate problems with a user opening multiple tabs over a span of time, and attempting to submit the first one opened? I believe the best practice is to provide the user's session id in their cookie and provide that with the requests via javascript or even at the time of page rendering. Since a third party (untrusted domain) cannot access information from your cookie, they also cannot form a valid request…
A session is shared between multiple browser tabs so this shouldn't be a problem. If the user opens a new tab/browser in incognito mode, then the browser will ask them to login in again b/c it can't read their session to authenticate their identity, and then when they login they will have two separate sessions going, each with a unique token/timestamp so multiple sessions isn't a problem either.
Re: JSON users: Avoid CSRFs by not using top-level arrays
#45Facebook is dealing with this by prefixing some of their JSON responses with "for(;;);".
Sometimes the laziest solutions are the most elegant.
They are adding executable code at the beginning of what is supposed to be a data structure. This solution is not elegant at all. It's an ugly hack that uses a side-effect of code to plug a hole in a rather convoluted security model.
Edit:
Come to think of it, this seems to be solvable by a much better method - the same one that is used to prevent standard CSRF. The problem is effectively the same.
Server A is a valid server. User logs into it and gains privileges. Then he visits server B, which is a bad server. B tricks the browser into sending a request to server A to do something (abusing the elevated privileges). The only addition with AJAX is that server B also manages to read the result of its attack. That wouldn't matter if it couldn't trick the server A honoring that page request in the first place.
You can easily solve this by signing your requests, effectively binding two pages on your server together. Normally, PAGE1 has a form (or JS code) that requests PAGE2. You simply need to enforce that only legal (yours) pages can do that. This is achieved by adding a token to PAGE1 that must be sent to PAGE2.
For example, token = hash(server_secret + PAGE2_identifier + user_id).
Upon receiving a request for PAGE2, the server will know all the arguments that went into creating that token, and re-generated. If the user-supplied token and server-generated tokens don't match, the request is denied.
As long as client side scripts from server B cannot read the token from server A, this should work even with AJAX requests. Since attacker (server B) cannot know server_secret, they will not be able to guess your generated token, and their requests to PAGE2 on server A will fail.
Re: JSON users: Avoid CSRFs by not using top-level arrays
#46I'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.)
I think it's just the ASP.Net AJAX Toolkit not plain ASP.Net or ASP.Net MVC.
Re: JSON users: Avoid CSRFs by not using top-level arrays
#47Earlier quoted context omitted.
How do you mitigate problems with a user opening multiple tabs over a span of time, and attempting to submit the first one opened? I believe the best practice is to provide the user's session id in their cookie and provide that with the requests via javascript or even at the time of page rendering. Since a third party (untrusted domain) cannot access information from your cookie, they also cannot form a valid request…
A session is shared between multiple browser tabs so this shouldn't be a problem. If the user opens a new tab/browser in incognito mode, then the browser will ask them to login in again b/c it can't read their session to authenticate their identity, and then when they login they will have two separate sessions going, each with a unique token/timestamp so multiple sessions isn't a problem either.
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.
Re: JSON users: Avoid CSRFs by not using top-level arrays
#48Earlier quoted context omitted.
A session is shared between multiple browser tabs so this shouldn't be a problem. If the user opens a new tab/browser in incognito mode, then the browser will ask them to login in again b/c it can't read their session to authenticate their identity, and then when they login they will have two separate sessions going, each with a unique token/timestamp so multiple sessions isn't a problem either.
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?
Re: JSON users: Avoid CSRFs by not using top-level arrays
#49An 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.
Re: JSON users: Avoid CSRFs by not using top-level arrays
#50Earlier quoted context omitted.
Having a CSRF token on your forms does not prevent, and has nothing to do with, with the attack in the article.
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 site, and you had an API (authenticated via HTTP sesions) that was a GET request go get the firends list. This method returned the (logged-in) users list of friends in a JS array.
Note that Django-style CSRF tokens are not relevant here, as they are only for protecting POSTs.
The attack described in the post is using a script tag, and a redefined array setter, to direct a user with a live logged-in session on your site to it to fetch data.
So coming back to my example. I am a malicious hacker, and I can socially engineer an end-user to come to my site. I put a script src=yoursocialnetwork.com/get_friend_list. This will fetch the data, and I will be able to extract that info in my javascript, and then post that back to my site so I can capture that info.