To be clear, this is not a CSRF attack in the usual sense. A standard CSRF attacks involves sending state-changing requests to a website using the credentials of an unsuspecting user. This is closer in nature to an information disclosure vulnerability and is identical to the security issues faced by JSONP APIs.
Note that the fix proposed here is fairly fragile. It doesn't actually rely on the same origin policy; it relies on the fact that browser JavaScript parsers have been modified to try and prevent attackers from reading the contents of files that are pure JSON (ie: http://directwebremoting.org/blog/joe/2007/03/05/json_is_not...).
Quite a few JSON interfaces not intended for cross-domain consumption rely on a somewhat fragile defense: the assumption that certain very specific object serializations ({ param: "value"}) or meaningless prefixes (&&&START&&&) will not parse via <SCRIPT SRC="...">; or that endless loop prefixes such as while (1) will prevent interception of the remainder of the data. In most cases, these assumptions are not likely to be future-safe; a better option is to require custom XMLHttpRequest headers, or employ a parser-breaking prefix that is unlikely to ever work as long as the basic structure of JavaScript is maintained. One such example is the string of )]}', followed by a newline.
3 comments
[ 3.1 ms ] story [ 12.3 ms ] threadNote that the fix proposed here is fairly fragile. It doesn't actually rely on the same origin policy; it relies on the fact that browser JavaScript parsers have been modified to try and prevent attackers from reading the contents of files that are pure JSON (ie: http://directwebremoting.org/blog/joe/2007/03/05/json_is_not...).
From the Browser Security Handbook (http://code.google.com/p/browsersec/wiki/Part2):
Quite a few JSON interfaces not intended for cross-domain consumption rely on a somewhat fragile defense: the assumption that certain very specific object serializations ({ param: "value"}) or meaningless prefixes (&&&START&&&) will not parse via <SCRIPT SRC="...">; or that endless loop prefixes such as while (1) will prevent interception of the remainder of the data. In most cases, these assumptions are not likely to be future-safe; a better option is to require custom XMLHttpRequest headers, or employ a parser-breaking prefix that is unlikely to ever work as long as the basic structure of JavaScript is maintained. One such example is the string of )]}', followed by a newline.
If you need the user's email or name on the client, put it into the HTML or load it via AJAX.