Comments on: Practical CSRF and JSON Security http://jon.sykes.me/47/practical-csrf-and-json-security Wed, 04 Feb 2009 22:11:07 +0000 http://wordpress.org/?v=2.6.2 By: Andrew http://jon.sykes.me/47/practical-csrf-and-json-security#comment-1756 Andrew Mon, 11 Aug 2008 13:00:26 +0000 http://jpsykes.com/47/practical-csrf-and-json-security#comment-1756 I dont understand how prepending while(1); to the beginning of your JSON achieves anything. If an attacker has decided they want to target your site, they will have read your JSON handling code and read the line that removes the while(1); and do the same thing in their exploit code. Am I missing something? I dont understand how prepending while(1); to the beginning of your JSON achieves anything. If an attacker has decided they want to target your site, they will have read your JSON handling code and read the line that removes the while(1); and do the same thing in their exploit code. Am I missing something?

]]> By: Eventhorizon http://jon.sykes.me/47/practical-csrf-and-json-security#comment-777 Eventhorizon Thu, 06 Mar 2008 14:45:46 +0000 http://jpsykes.com/47/practical-csrf-and-json-security#comment-777 Sorry folks. As far as I read in the DWR's Javascript security documentation, DWR seems to "solve" the problem for me. Sorry folks. As far as I read in the DWR’s Javascript security documentation, DWR seems to “solve” the problem for me.

]]> By: Eventhorizon http://jon.sykes.me/47/practical-csrf-and-json-security#comment-776 Eventhorizon Thu, 06 Mar 2008 14:09:34 +0000 http://jpsykes.com/47/practical-csrf-and-json-security#comment-776 Hi folks! So after all, what is the result of this discussion? I am a greenhorn - in reference to "ajax" with json. I use dwr for all of my ajax calls. So what do I have to do to make this more secure? Is it possible at all? For me it sounds like the "unique-token-story" is what I would have to realize. Can anyone tell me how? In my opinion I would create a unique id on the server side and put it into the page as... as what? A hidden input, a javascript var? What if there are several ajax-calls at the same time? I read about a changing unique id for every call. Would this force me to use synchronized calls?!? I simply do not understand this. THX for reading this - and maybe a short answer... :-) EH Hi folks!
So after all, what is the result of this discussion?
I am a greenhorn - in reference to “ajax” with json. I use dwr for all of my ajax calls.
So what do I have to do to make this more secure?
Is it possible at all?
For me it sounds like the “unique-token-story” is what I would have to realize.
Can anyone tell me how?
In my opinion I would create a unique id on the server side and put it into the page as… as what? A hidden input, a javascript var? What if there are several ajax-calls at the same time? I read about a changing unique id for every call. Would this force me to use synchronized calls?!?
I simply do not understand this.
THX for reading this - and maybe a short answer… :-)
EH

]]> By: JP http://jon.sykes.me/47/practical-csrf-and-json-security#comment-739 JP Thu, 10 Jan 2008 02:32:00 +0000 http://jpsykes.com/47/practical-csrf-and-json-security#comment-739 Kezzel, yeah I've seen both of those, Dojo added the comment removal 'hack' to their JSON IO defaults (if your JSON return doesn't have comments wrapped round it, it actually throws a debug warning. Personally I don't like that as a solution, it doesn't solve the real underlying issue that your data is accessible to somewhere nefarious, it just stops that data from being <em>currently</em> exploited. Personally I'd rather have security that stops data from being passed about to places where it's not intended, and for that to happen the responsibility needs to rest on the server. The server should be responsible for stopping the attack, rather than trying to find ways to make it hard to do anything once the attack has occurred. Kezzel, yeah I’ve seen both of those, Dojo added the comment removal ‘hack’ to their JSON IO defaults (if your JSON return doesn’t have comments wrapped round it, it actually throws a debug warning.

Personally I don’t like that as a solution, it doesn’t solve the real underlying issue that your data is accessible to somewhere nefarious, it just stops that data from being currently exploited.

Personally I’d rather have security that stops data from being passed about to places where it’s not intended, and for that to happen the responsibility needs to rest on the server. The server should be responsible for stopping the attack, rather than trying to find ways to make it hard to do anything once the attack has occurred.

]]> By: Kezzel http://jon.sykes.me/47/practical-csrf-and-json-security#comment-726 Kezzel Fri, 07 Dec 2007 10:49:54 +0000 http://jpsykes.com/47/practical-csrf-and-json-security#comment-726 Another approach exists where the actual access to the JSON text exclusively given to the code running in the good.com domain is exploited. The idea is very simply to avoid code from evil.com being able to execute the json code from good.com in a script tag, but let code from good.com execute it by changing it a little, since the later has access to the actual text. I normally prepend a 'while(1);' to the json data and wrap it all in comment string '/*...*/'. When parsing the json data, it is simply removed using a regular expression: json_string = sjson_string.replace(/^\/\*while\(1\);(.*)\*\/$/,"$1"); This is much faster than parsing XML, and avoids CSRF. Another approach exists where the actual access to the JSON text exclusively given to the code running in the good.com domain is exploited. The idea is very simply to avoid code from evil.com being able to execute the json code from good.com in a script tag, but let code from good.com execute it by changing it a little, since the later has access to the actual text.

I normally prepend a ‘while(1);’ to the json data and wrap it all in comment string ‘/*…*/’. When parsing the json data, it is simply removed using a regular expression:

json_string = sjson_string.replace(/^\/\*while\(1\);(.*)\*\/$/,”$1″);

This is much faster than parsing XML, and avoids CSRF.

]]> By: JP http://jon.sykes.me/47/practical-csrf-and-json-security#comment-290 JP Thu, 13 Sep 2007 01:02:53 +0000 http://jpsykes.com/47/practical-csrf-and-json-security#comment-290 Very true Chris, my wording is wrong. My point was more that if people are worried about this stuff they need to look at whether they have other security considerations in place. I'd wager that the json data they are worrying about is being sent over regular http, so they might want to be worrying about other things as well. Very true Chris, my wording is wrong. My point was more that if people are worried about this stuff they need to look at whether they have other security considerations in place. I’d wager that the json data they are worrying about is being sent over regular http, so they might want to be worrying about other things as well.

]]> By: Chris Clark http://jon.sykes.me/47/practical-csrf-and-json-security#comment-289 Chris Clark Thu, 13 Sep 2007 00:27:03 +0000 http://jpsykes.com/47/practical-csrf-and-json-security#comment-289 In the "Do security correctly." area you mention that sensitive applications should be hosted over SSL. How does that mitigate the JSON hijacking attack? If the data is retrievable using a predictable query string then the data may still be fetched and disclosed regardless. Your idea of adding a CSRF-protection style unique token per request seems to me to be the perfect solution. SSL just won't help. In the “Do security correctly.” area you mention that sensitive applications should be hosted over SSL. How does that mitigate the JSON hijacking attack? If the data is retrievable using a predictable query string then the data may still be fetched and disclosed regardless. Your idea of adding a CSRF-protection style unique token per request seems to me to be the perfect solution. SSL just won’t help.

]]> By: jpsykes » CSRF - How about setting a header? http://jon.sykes.me/47/practical-csrf-and-json-security#comment-10 jpsykes » CSRF - How about setting a header? Tue, 10 Apr 2007 14:12:23 +0000 http://jpsykes.com/47/practical-csrf-and-json-security#comment-10 [...] Practical CSRF and JSON Security (2) [...] [...] Practical CSRF and JSON Security (2) [...]

]]> By: JP http://jon.sykes.me/47/practical-csrf-and-json-security#comment-9 JP Fri, 06 Apr 2007 20:16:35 +0000 http://jpsykes.com/47/practical-csrf-and-json-security#comment-9 Yup, that is partly the point I was trying to get across. There is a lot of fuss about JSON vulnerability, but many of the exploits that are documented are not using pure JSON. That said, many people use the term JSON to refer to examples that aren't actually JSON. Technically 1 is valid JSON (atleast according to <a href="http://www.ietf.org/rfc/rfc4627.txt" rel="nofollow">RFC4627</a>). As I mentioned it's not a format I've seen used much, so for me it's less of an issue. Regarding your comment on 5, that is my point. The expoit as far as I can tell is not an exploit. Although it has been blogged about at length as an issue. My final point however is that all of this 'should' be moot. If you're dealing with information that is sensitive enough that you are worried about security you shouldn't be relying on how the browser does or doesn't handle the parsing of the script tag, you want to avoid sending that data out. Which is why at the moment, I like the idea of adding something unique (unique to the form, the user and the time) to all forms that so you can then match up requests with 'officially' generated forms. This may of course change. Security is fluid. Yup, that is partly the point I was trying to get across. There is a lot of fuss about JSON vulnerability, but many of the exploits that are documented are not using pure JSON.

That said, many people use the term JSON to refer to examples that aren’t actually JSON.

Technically 1 is valid JSON (atleast according to RFC4627). As I mentioned it’s not a format I’ve seen used much, so for me it’s less of an issue.

Regarding your comment on 5, that is my point. The expoit as far as I can tell is not an exploit. Although it has been blogged about at length as an issue.

My final point however is that all of this ’should’ be moot. If you’re dealing with information that is sensitive enough that you are worried about security you shouldn’t be relying on how the browser does or doesn’t handle the parsing of the script tag, you want to avoid sending that data out. Which is why at the moment, I like the idea of adding something unique (unique to the form, the user and the time) to all forms that so you can then match up requests with ‘officially’ generated forms. This may of course change. Security is fluid.

]]> By: Bob Ippolito http://jon.sykes.me/47/practical-csrf-and-json-security#comment-8 Bob Ippolito Fri, 06 Apr 2007 20:03:15 +0000 http://jpsykes.com/47/practical-csrf-and-json-security#comment-8 2, 3, and 4 are not technically JSON. 2 and 3 are common extensions intended to allow cross-domain data transfer by way of JavaScript, so saying they're vulnerable to csrf is a little silly. I've never seen 4 in the wild, I don't really see why anyone would do that. 5, the "good format" is not exploitable with any current or past browser because object literals don't parse without more context (the parentheses). The grammar thinks {foo: ...} is a label, not a key. It will not be exploitable as a script execution attack unless some future JavaScript specification changes the grammar to remove labels and some future browser implements this change. 2, 3, and 4 are not technically JSON. 2 and 3 are common extensions intended to allow cross-domain data transfer by way of JavaScript, so saying they’re vulnerable to csrf is a little silly. I’ve never seen 4 in the wild, I don’t really see why anyone would do that.

5, the “good format” is not exploitable with any current or past browser because object literals don’t parse without more context (the parentheses). The grammar thinks {foo: …} is a label, not a key. It will not be exploitable as a script execution attack unless some future JavaScript specification changes the grammar to remove labels and some future browser implements this change.

]]>