<br><div class="gmail_quote">On Mon, Mar 29, 2010 at 2:12 AM, Jon mailinglists <span dir="ltr">&lt;<a href="mailto:jon.mlist@gmail.com">jon.mlist@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
</div>It seems like it is. I just stumbled upon this when checking out YUI<br>
3, and had managed to stay oblivious to this problem before. I then<br>
went on with checking if one could make an attack that way and got a<br>
bit scared by the results and asked here. Classic case of reinventing<br>
wheels. I called it XSS because I figured it was scripts running<br>
across sites, but apparently this is XSRF as you said.<br></blockquote><div><br></div><div>I think you are missing it still. It&#39;s not really XSRF.</div><div><br></div><div>These terms are a bit fuzzy and overloaded, but in general:</div>

<div><br></div><div>XSS is where an attacker places script on the attacked site.  This is accomplished by correctly not filtering user input.  One example is a blog site where the attacker places script on a common page that many others view.  Another approach is for the attacker to create a link to the site they wish to attack which includes javascript and trick people into clicking the link.</div>

<div>When the script runs it can, for example, send the cookie to the attacker&#39;s site and then the user can use that session id to gain access.</div><div><br></div><div>XSRF is (typically, AFAIK) where the attacker&#39;s site includes a tag that generates a request to another site.  Wikipedia is worth reading, and it includes this example:</div>

<div><br></div><div>&lt;img src=&quot;<a href="http://bank.example/withdraw?account=bob&amp;amount=1000000&amp;for=mallory">http://bank.example/withdraw?account=bob&amp;amount=1000000&amp;for=mallory</a>&quot;&gt;</div><div>

<br></div><div>The attacker has to know (or hope) the person that is viewing the page with the &lt;img&gt;  has an account at bank.example and that they are logged in (or have a &quot;remember me&quot; cookie).</div><div>

<br></div><div>Of course, the &lt;img&gt; does a GET request to the poorly-coded bank site and incorrectly causes something to happen.  This works because the browser will send the cookie with the request.</div><div><br>
</div>
<div>Now to your example.   It&#39;s ok to load and run javascript from a third party site.  And any data that javascrpt brings in will be available to the page that is loading the script.  This is expected.  It&#39;s also expected that the browser will send the site&#39;s cookie along with the request.</div>

<div><br></div><div>Your example seems like XSRF because the attacking site is requesting a resource (javascript) from your site -- just like the &lt;img&gt; above is making a request to another site.  It&#39;s also similar because in both your example and the XSRF example above, the site is doing something dumb.</div>

<div><br></div><div>The bank.example site is dumb because it&#39;s allowing a GET request to make a change.  Your example is making the mistake of providing javascript that gives private data away.</div><div><br></div><div>

And that&#39;s why AJAX requests follow same-origin policy.  It provides a way to fetch data from a site, but only from the site that the browser is viewing.</div><div><br></div><div>(Sure, the attacking site could create a form (perhaps in a hidden iframe) and POST that, but hopefully your bank will return an &quot;Are you sure you want to transfer your money to Mallory?&quot; confirmation screen first.)</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br></div>
Wouldn&#39;t it make sense to have and option in Authorization which<br>
generates and stores a token server side, in either a database or in<br>
the session (like Bill seems to do) at login time. If I&#39;m not horribly<br>
mistaken would one token be enough for a session since the attack is<br>
blind and there&#39;s no way for a 3rd party to figure it out unless using<br>
brute force.<br>
<br>
If that is correct, one can go about playing CRUD and allowing<br>
/member/get_info?token=... and /member/set_info?token=... with GET<br>
requests?<br></blockquote><div><br></div><div>First, don&#39;t set_info with a GET request.  That just makes the XSRF easy.  Second, if this is to protect against your example that returns JSONP (and thus leaks personal user info) then, the real solution is to not return JSONP.</div>

<div><br></div><div>I think the tokens are a mixed bag.  Yes, the tokens would help, but if you have them on your URLs then you have to worry about bookmarking and link leaking.  The tokens I use help with POSTing forms, but for critical changes I still add an &quot;Are you sure?&quot; page.</div>

<div><br></div><div> </div></div><br>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org">moseley@hank.org</a><br>