CSRF Attack using JavaScript(futuresimple.github.com)
futuresimple.github.com
CSRF Attack using JavaScript
http://futuresimple.github.com/posts/2012-03-04-csrf-attack/
3 comments
The only thing to ever put in a cookie is the SESSION ID! Never put any user credentials into a cookie!
If you need the user's email or name on the client, put it into the HTML or load it via AJAX.
If you need the user's email or name on the client, put it into the HTML or load it via AJAX.
This isn't really a CSRF attack, and serving up content specific to the current user through a JavaScript file is an odd practice to begin with.
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.