11–20 of 85 posts
https://github.com/documentcloud/backbone/issues/201
ultimately you should use tokens to verify the request was not forged.
Earlier 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…
Earlier 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…
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 tag from the attacker's site.
Earlier quoted context omitted.
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]
Facebook is dealing with this by prefixing some of their JSON responses with "for(;;);".
Sometimes the laziest solutions are the most elegant.
tl;dr Sometimes ugly is elegant, too.
[1] http://perl.plover.com/yak/12views/samples/notes.html#sl-3
Earlier 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…
Earlier 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…
This will stop embedding it in but why couldn't the attacking website do the same with eval and substring?
https://secure.wikimedia.org/wikipedia/en/wiki/Same_origin_p...
Generally speaking, all incoming requests should be verified - authorized or not. These days with all kinds of wonderful web frameworks, CSRF protection is pretty simple. Django handles CSRF with a token in a hidden form field: https://docs.djangoproject.com/en/dev/ref/contrib/csrf/
Generally speaking, all incoming requests should be verified - authorized or not. These days with all kinds of wonderful web frameworks, CSRF protection is pretty simple. Django handles CSRF with a token in a hidden form field: https://docs.djangoproject.com/en/dev/ref/contrib/csrf/