CSRF Attack using JavaScript
futuresimple.github.com
futuresimple.github.com
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...).
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.