我读的教程在防止跨站点请求伪造 - 不要在小甜饼报头发送到服务器的SessionID的依靠
http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ
它指出
记住 - 你必须永远不要依靠 cookieID发送到您的服务器的sessionID;请仅查看 会话ID，以便您的GWT应用程序将 明确地在消息的有效负载 中发送到您的服务器。
是用它来防止http://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics
有了这个神话，是不是足以防止上述攻击？
是的，它足以防止跨站请求伪造。
cookie中的sessionid不可信。假设用户登录到mysite.com，会话ID在cookie中。现在用户点击链接到evilsite.com。 evilsite.com有这样的代码
<img src="http://mysite.com/transfermoney.jsp?amount=1000.." />
浏览器会主动要求到mysite.com，和它也将随会话ID发送cookie。这里要理解的是，evilsite.com 不能读取cookie，但它仍然可以完成它的工作。
浏览器同源策略可防止evilsite.com读取会话标识符，无论是在cookie中还是嵌入在html页面中。但是，由于浏览器自动将cookie发送到服务器，即使资源是从其他域中的html代码请求的，您也有XSRF。
为防止出现这种情况，建议将会话标识符作为请求参数。如果将其作为请求参数添加，evilsite.com将无法访问标识符，因此无法将其置于img src属性中。
但是，请记住，如果您的网站存在XSS漏洞，则任何事情都无法阻止您从XSRF中获得。换句话说，如果你有XSS漏洞，攻击者甚至不会在乎做XSRF。
@Sripathi：对于一个非常好的问题，这是一个非常好的答案！我看到的实际问题是，人们习惯于“保持登录状态”，即使他们关闭了一个浏览器窗口，或者如果他们使用其他浏览器窗口访问同一网站 - 他们希望仍然登录。所以如果我的网站并未提供该功能（以对付CSRF攻击），恐怕他们会将我的网站视为“低质量” - 即“为什么其他网站可以这样做，但不是您的？”我实际上可以理解这种态度。有没有什么方法可以将两个优点结合起来，或者找到一个好的折中方案？ – 2010-04-05 19:40:45
这是可能的。 CSRF主要是AJAX风格的APIS的一个问题，其中只需要一个请求即可完成有害的事情。对于这样的api请求，你不应该只依赖长寿的记住我cookie。但是，仅使用cookie呈现只读页面是可以的 - 因为攻击者无法使用csrf来读取内容。 – 2010-04-06 01:08:04
我认为，这是最好的折中方案。但是我仍然有点不确定，因为我记得阅读过一篇文章（http://directwebremoting.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is。HTML）关于如何从CSRF的回复中窃取某些类型的数据的技术，虽然它不应该是可能的。我希望，这是不可能超越JavaScript的结果，因为我们可以安全地假设它打破了第一个“<”字符左右？如果我们不能，用户实际上必须分别登录每个浏览器选项卡... – 2010-04-06 11:43:07