Hacker News Reader

Comment by sonnym | Hacker News Reader

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.

View on HN

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.

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.

This is good advice, but a non-sequitur in this case. This is not a code-injection attack, this is an information leak. It lets an attacker get around the normal constraints on fetching cross-site URLs. There is an EVAL happening, but it's being done by the attacker, not by you. And it's being done implicitly. The real problem here is a security hole in Javascript itself. It's too flexible for its own good.

I agree that eval() is evil and JSON.parse() is the way to go.

However, in this particular case this doesn't matter much, because the site itself controls where to load the JSON from. Manipulating the JSON response requires access to the webserver or the DNS, and in those cases the attacker could have manipulated the initial HTML response as well.

> 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.

This totally misses the context of the article. The article is about CSRF. That is, the _attacker_ downloads and executes the JSON.

This is _not_ about downloading the attacker's JSON! It is about how to construct the JSON in a way that it is unaccessible through a <script> tag from the attacker's site.

This will stop embedding it in <script> but why couldn't the attacking website do the same with eval and substring?

Because you cannot issue cross-domain AJAX calls, the attacker does not have access to the response body as a string that can be manipulated.

https://secure.wikimedia.org/wikipedia/en/wiki/Same_origin_p...

Oh duh, I'm dumb.

Reply on news.ycombinator.com