

CSRF Attack using JavaScript - kiszal
http://futuresimple.github.com/posts/2012-03-04-csrf-attack/

======
nbpoole
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...](http://directwebremoting.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is.html)).

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._

------
yaix
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.

------
richardhenry
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.

