JSON users: Avoid CSRFs by not using top-level arrays
flask.pocoo.org
JSON users: Avoid CSRFs by not using top-level arrays
1–10 of 85 posts
Re: JSON users: Avoid CSRFs by not using top-level arrays
#2Facebook is dealing with this by prefixing some of their JSON responses with "for(;;);".
Re: JSON users: Avoid CSRFs by not using top-level arrays
#3Facebook is dealing with this by prefixing some of their JSON responses with "for(;;);".
Sometimes the laziest solutions are the most elegant.
Re: JSON users: Avoid CSRFs by not using top-level arrays
#4Facebook is dealing with this by prefixing some of their JSON responses with "for(;;);".
OK, I see how that prevents an attack (it seems to create an endless loop), but how does this parse as regular JSON for the good guys?
Re: JSON users: Avoid CSRFs by not using top-level arrays
#5Facebook is dealing with this by prefixing some of their JSON responses with "for(;;);".
OK, I see how that prevents an attack (it seems to create an endless loop), but how does this parse as regular JSON for the good guys?
I imagine they simply remove the first 8 characters from the response string. eval("(for(;;);{})"); doesn't work, but eval("(" + "for(;;);{}".substring(8, 10) + ")"); works fine where 10 is the length of the response string.
EDIT: This is the correct idea. Search for shieldlen or safeResponse in the JS to see how it is implemented. There is always something interesting to be learned by digging through FB's client side code.
Re: JSON users: Avoid CSRFs by not using top-level arrays
#6I'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 came from the browser of an authorized user. Because browsers run code sent by multiple sites, there is a danger that one site will (unbeknownst to the user) send a request to a second site, and the second site will mistakenly think that the user authorized the request.
From: http://freedom-to-tinker.com/blog/wzeller/popular-websites-v...
Via: http://www.codinghorror.com/blog/2008/10/preventing-csrf-and...
Re: JSON users: Avoid CSRFs by not using top-level arrays
#7Facebook is dealing with this by prefixing some of their JSON responses with "for(;;);".
Yes and Google has 'throw 1;' at the start of some of their files IIRC (may be some other value than '1').
Re: JSON users: Avoid CSRFs by not using top-level arrays
#8Earlier quoted context omitted.
OK, I see how that prevents an attack (it seems to create an endless loop), but how does this parse as regular JSON for the good guys?
I imagine they simply remove the first 8 characters from the response string. eval("(for(;;);{})"); doesn't work, but eval("(" + "for(;;);{}".substring(8, 10) + ")"); works fine where 10 is the length of the response string. EDIT: This is the correct idea. Search for shieldlen or safeResponse in the JS to see how it is implemented. There is always something interesting to be learned by digging through FB's client sid…
You should never be eval()ing json, thats the most dangerous thing you can do with it. All browsers have had native JSON parsers for years, which will choke on any code that's sent through them. These will be automatically employed by any js framework you're using, or I think its generally JSON.parse().
By eval()ing your json you are doing most of the attackers work for them. All that stuff in the article about mime types is redundant if you're eval()ing your json.
Basically, don't ever eval() anything, in any language.
Re: JSON users: Avoid CSRFs by not using top-level arrays
#9Earlier quoted context omitted.
I imagine they simply remove the first 8 characters from the response string. eval("(for(;;);{})"); doesn't work, but eval("(" + "for(;;);{}".substring(8, 10) + ")"); works fine where 10 is the length of the response string. EDIT: This is the correct idea. Search for shieldlen or safeResponse in the JS to see how it is implemented. There is always something interesting to be learned by digging through FB's client sid…
You should never be eval() ing json, thats the most dangerous thing you can do with it. All browsers have had native JSON parsers for years, which will choke on any code that's sent through them. These will be automatically employed by any js framework you're using, or I think its generally JSON.parse(). By eval()ing your json you are doing most of the attackers work for them. All that stuff in the article about mime…
While I generally agree with your sentiment, I was merely writing a brief proof of concept test in the firebug console.
From: http://www.json.org/js.html
"The use of eval is indicated when the source is trusted and competent. It is much safer to use a JSON parser."
FB is still using eval() if you look at their code. As the source of the JSON is their own service, and they can, therefore, trust it assuming proper sanitization; the same applies for my test case.
Re: JSON users: Avoid CSRFs by not using top-level arrays
#10Earlier quoted context omitted.
I imagine they simply remove the first 8 characters from the response string. eval("(for(;;);{})"); doesn't work, but eval("(" + "for(;;);{}".substring(8, 10) + ")"); works fine where 10 is the length of the response string. EDIT: This is the correct idea. Search for shieldlen or safeResponse in the JS to see how it is implemented. There is always something interesting to be learned by digging through FB's client sid…
You should never be eval() ing json, thats the most dangerous thing you can do with it. All browsers have had native JSON parsers for years, which will choke on any code that's sent through them. These will be automatically employed by any js framework you're using, or I think its generally JSON.parse(). By eval()ing your json you are doing most of the attackers work for them. All that stuff in the article about mime…
[deleted]