1. 如何避免CSRF攻击
CSRF是一种让人难以防范的漏洞，据歪歪了解，目前没有很好的监测CSRF的方法。歪歪想到的一些比较可行的防范方法：
不使用网银。所谓的无招胜有招，我既然不用网银，黑客也就自然巧媳妇难为无米之炊了。（just a joke:)）
定期修改密码。定期修改密码永远是安全学中最提倡的一个方法。
访问敏感网站（比如信用卡、网银等）后，主动清理历史记录、cookie记录、表单记录、密码记录，并重启浏览器才访问其他网站。
保持浏览器更新补丁，尤其是安全补丁。同时也要留意操作系统、杀毒、防火墙等软件的更新。
不要上来历不明的网站，推荐使用ms ie7的站点认证功能或者google toolbar之类辨识非法的网站。
使用某些带有“隐私浏览”功能的浏览器，比如Safari。“隐私浏览”功能可以让用户在上网冲浪时不会留下任何痕迹, 浏览器不会存储cookie和其它任何资料。从而CSRF也拿不到有用的信息。
ie8把它叫做“InPrivate浏览”。Chrome称作“Incognito模式”。
如果浏览器提示“链接和证书域名不匹配”的警告信息时，请不要继续浏览，立即关闭浏览器或者返回上一页（如果您是网页开发者或者黑客，当我没有说）。
管理好浏览器的cookie。比如在IE6.0中，打开“工具->Intern
2. CSRF 攻击是什么
说明: 本文大部分借鉴 wiki-跨站请求伪造 , 另一部分来自文章 wiki-Cross-Site Request Forgery
csrf 全称 Cross-site request forgery, 通常缩写为CSRF 或者 XSRF, 中文名跨站请求伪造. 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。 . CSRF 攻击手段是通过发起改变状态的请求, 而不是窃取用户的数据, 因为攻击者无法得到服务器返回的响应
攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞： 简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。 补充: 还可能更改账号所绑定的邮箱地址或者密码等.
假如 Alice 在 bank.com 向 Bob 汇款 10000, 那么攻击将会由以下两步骤组成:
如果 bank.com 把查询参数放到 URL 中, 那么 Alice 向 Bob 转账的操作可以简化为如下:
GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1
Maria 根据 bank.com 网站请求的结构, 将 Bob 名字替换为她自己的, 还把金额变大:
http://bank.com/transfer.do?acct=MARIA&amount=100000
那么这个充满恶意的 URL ,被 Maria 放到 a 标签中, 并且利用欺骗语言吸引 Alice 点击:
<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>
或者放到一个 长度和宽度都为0 的图片的src 中(图片不用用户点击, 自己就发起请求):
<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0">
如果这张图片放到邮件中, Alice 根本就不会发现什么. 然而浏览器还是会将请求提交到 bank.com 的后台中.
一个真实的事件是发生在2008 年的 uTorrent exploit
假设 bank.com 现在使用 post 请求来传递参数的, 那么这个请求可以简化为:
这种情况下, a 标签和 img 标签都无法发送 post 请求, 但是可以使用 FORM 来完成:
我们还可以利用 JavaScript 来让文档载入的时候就发送这个请求:
假设现在银行使用的是 PUT 将数据放到一个JSON 中发送到后台中:
那么我们可以利用内嵌的 JavaScript :
幸运的是这段 PUT 请求并不会发送, 因为 同源策略 的限制. 除非你的后台设置了
不论是 GET 请求还是 POST 请求, 如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失10000资金。
这种恶意的网址可以有很多种形式，藏身于网页中的许多地方。此外，攻击者也不需要控制放置恶意网址的网站。例如他可以将这种地址藏在论坛，博客等任何用户生成内容的网站中。这意味着 如果服务器端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。
3. csrf的具体含义
Cross-site request forgery:跨站请求伪造，也被称成为“one click attack”或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
示例和特性
« ‹ › »
CSRF攻击通过在授权用户访问的页面中包含链接或者脚本的方式工作。例如：一个网站用户Bob可能正在浏览聊天论坛，而同时另一个用户Alice 也在此论坛中，并且后刚刚发布了一个具有Bob银行链接的图片消息。设想一下，Alice编写了一个在Bob的银行站点上进行取款的form提交的链接，并将此链接作为图片tag。如果Bob的银行在cookie中保存他的授权信息，并且此cookie没有过期，那么当Bob的浏览器尝试装载图片时将提交这个取款form和他的cookie，这样在没经Bob同意的情况下便授权了这次事务。
CSRF是一种依赖web浏览器的、被混淆过的代理人攻击（deputy attack）。在上面银行示例中的代理人是Bob的web浏览器，它被混淆后误将Bob的授权直接交给了Alice使用。
下面是CSRF的常见特性：
依靠用户标识危害网站
利用网站对用户标识的信任
欺骗用户的浏览器发送HTTP请求给目标站点
风险在于那些通过基于受信任的输入form和对特定行为无需授权的已认证的用户来执行某些行为的web应用。已经通过被保存在用户浏览器中的cookie进行认证的用户将在完全无知的情况下发送HTTP请求到那个信任他的站点，进而进行用户不愿做的行为。
使用图片的CSRF攻击常常出现在网络论坛中，因为那里允许用户发布图片而不能使用JavaScript。
防范措施
« ‹ › »
对于web站点，将持久化的授权方法（例如cookie或者HTTP授权）切换为瞬时的授权方法（在每个form中提供隐藏field），这将帮助网站防止这些攻击。一种类似的方式是在form中包含秘密信息、用户指定的代号作为cookie之外的验证。
另一个可选的方法是“双提交”cookie。此方法只工作于Ajax请求，但它能够作为无需改变大量form的全局修正方法。如果某个授权的 cookie在form post之前正被JavaScript代码读取，那么限制跨域规则将被应用。如果服务器需要在Post请求体或者URL中包含授权cookie的请求，那么这个请求必须来自于受信任的域，因为其它域是不能从信任域读取cookie的。
与通常的信任想法相反，使用Post代替Get方法并不能提供卓有成效的保护。因为JavaScript能使用伪造的POST请求。尽管如此，那些导致对安全产生“副作用”的请求应该总使用Post方式发送。Post方式不会在web服务器和代理服务器日志中留下数据尾巴，然而Get方式却会留下数据尾巴。
尽管CSRF是web应用的基本问题，而不是用户的问题，但用户能够在缺乏安全设计的网站上保护他们的帐户：通过在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie。
影响CSRF的因素
«‹ › »
CSRF攻击依赖下面的假定：
攻击者了解受害者所在的站点
攻击者的目标站点具有持久化授权cookie或者受害者具有当前会话cookie
目标站点没有对用户在网站行为的第二授权
外部链接
4. 360浏览器在填写回复帖子时候出现错误提示框：csrf token error。该怎么解决
你好，我觉的出现你这样的情况应该是你访问的网站与你使用的浏览器在某些方面存在冲突，你可以换一种兼容性较强的浏览器 比如有QQ浏览器，他的内核在IE浏览器的基础上做了升级优化。使他的兼容性很强能很好的访问大多数的网站。另外QQ浏览器的安装包也很小方便下载使用。也不会占用过多的内存。还望采纳