<br><br><div class="gmail_quote">On Sun, Mar 28, 2010 at 3:13 PM, Tomas Doran <span dir="ltr">&lt;<a href="mailto:bobtfish@bobtfish.net">bobtfish@bobtfish.net</a>&gt;</span> wrote:<br><div><br></div><div>Speaking of XSRF:</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"></div>
It would be possible to parse the HTML your app output, add an extra hidden field to any forms you had generated in the page, and then look for a previously generated token and redirect / refuse the request if it wasn&#39;t present.<br>

</blockquote><div><br></div><div>I do this -- every POST must include token, and the token can only be used once.  That means the the form must be fetched before bing posted (to generate the token).</div><div><br></div><div>

I&#39;m not sure I understand XSRF enough to know if there&#39;s a way to get around the token (or trick the browser into doing a POST for, say, and &lt;img&gt;.<br><br></div><div>And for a SSL only site that requires login, I&#39;m also not so sure the token requirement helps that much for security.  The original purpose was to slow down form spamming and to prevent double-posting of forms.</div>

<div><br></div><div>The tokesn don&#39;t work so well with an API, of course, but XSRF needs a browser, AFAIK (hard to trick a user of an API into making a request..)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


However this would obviously not catch forms generated purely from Javascript (and a number of other cases), and so I&#39;m somewhat doubtful of its value in more complex applications. I can certainly remember the stuff which tries to achieve this that is baked into Rails making me scream :)<br>

</blockquote><div><br></div><div>I&#39;m not clear how javascript is an issue here, unless the attacker has injected javascript into my site.</div><div><br></div><div>The example on Wikipedia for XSRF is to add a link to your bank on the attackers site, which you view:</div>

<div><span class="Apple-style-span" style="font-family: monospace, sans-serif; font-size: 13px; line-height: 19px; ">&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;</span></div>

<div><font class="Apple-style-span" face="monospace, sans-serif"><span class="Apple-style-span" style="line-height: 19px;"><br></span></font></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif"><span class="Apple-style-span" style="line-height: 19px;">Which is a pretty bad bank that allows that.  A third-party (evil) page can include the above and force a GET request that is not noticed, but to make a POST it would have to have a form where the response is from the bank.  That is, you would see the bank&#39;s response page.  Can&#39;t do it via an AJAX request because of the same-origin policy.</span></font></div>

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