<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: One-time Form tokens</title>
	<atom:link href="http://www.thespanner.co.uk/2007/04/12/one-time-form-tokens/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.thespanner.co.uk/2007/04/12/one-time-form-tokens/</link>
	<description>A tool for designers dealing with programmers dealing with designers...</description>
	<pubDate>Tue, 30 Sep 2008 23:28:05 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: Gareth Heyes</title>
		<link>http://www.thespanner.co.uk/2007/04/12/one-time-form-tokens/#comment-545</link>
		<dc:creator>Gareth Heyes</dc:creator>
		<pubDate>Fri, 07 Sep 2007 09:10:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.thespanner.co.uk/2007/04/12/one-time-form-tokens/#comment-545</guid>
		<description>Hi Joseph

If you only used cookies then it would be possible for an attacker to perform any action on your behalf by including an iframe on their site and forcing you to do an action.

Form tokens are not the only method you can use, I've done a newer post which explains various techniques:-
http://www.thespanner.co.uk/2007/08/21/protection-against-csrf-part-2/

If you randomise the URL on every login this can be a good way of protecting against CSRF but check out the examples above to see which is best for you.</description>
		<content:encoded><![CDATA[<p>Hi Joseph</p>
<p>If you only used cookies then it would be possible for an attacker to perform any action on your behalf by including an iframe on their site and forcing you to do an action.</p>
<p>Form tokens are not the only method you can use, I&#8217;ve done a newer post which explains various techniques:-<br />
<a href="http://www.thespanner.co.uk/2007/08/21/protection-against-csrf-part-2/" rel="nofollow">http://www.thespanner.co.uk/2007/08/21/protection-against-csrf-part-2/</a></p>
<p>If you randomise the URL on every login this can be a good way of protecting against CSRF but check out the examples above to see which is best for you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joseph Wilk</title>
		<link>http://www.thespanner.co.uk/2007/04/12/one-time-form-tokens/#comment-544</link>
		<dc:creator>Joseph Wilk</dc:creator>
		<pubDate>Fri, 07 Sep 2007 08:48:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.thespanner.co.uk/2007/04/12/one-time-form-tokens/#comment-544</guid>
		<description>Hello,

It sounds like a good solution. It would be good for me but I have systems where its an issues to store server state. I try and operate with a REST model trying to ensure that there is little to no state at the server. Using cookies where possible for logins. Is it impossible to protect against this sort of attack without relying on server state? 

Thanks</description>
		<content:encoded><![CDATA[<p>Hello,</p>
<p>It sounds like a good solution. It would be good for me but I have systems where its an issues to store server state. I try and operate with a REST model trying to ensure that there is little to no state at the server. Using cookies where possible for logins. Is it impossible to protect against this sort of attack without relying on server state? </p>
<p>Thanks</p>
]]></content:encoded>
	</item>
</channel>
</rss>
