CSRF(cross-siterequestforgery )，中文名称:交叉网站请求伪造，又称one click attack/session riding，简称CSRF/XSRF。
那么CSRF到底能做什么呢？ 攻击者可以很容易地理解为盗用你的登录信息，作为你可以模拟发送各种各样的请求。 攻击者只需利用社交技巧，例如通过QQ等聊天软件发送的链接，即可使网络APP用户执行攻击者预设的操作。 例如，如果用户登录网上银行确认存款余额，并在他未退出时单击QQ好友的链接，则该用户银行帐户中的资金可能会移动到攻击者指定的帐户。
因此，当遇到CSRF攻击时，对最终用户的数据和操作指令构成严重威胁； 如果受到攻击的最终用户具有管理员帐户，则CSRF攻击会危及整个web APP应用程序。
CSRF原理为了完成一次CSRF攻击，受害者必须按顺序完成两个步骤
1 .登录受信任的站点a并在本地生成cookie。 2 .在不退出a的情况下，访问危险网站b。 看到这里，读者可能会问:“如果我不满足这两个条件中的任何一个，就不会受到CSRF的攻击。” 是的，确实是这样，但我不能保证下次不会发生。
无法保证登录到一个站点后，将打开一个选项卡不再访问另一个站点。 特别是现在，浏览器支持多标签。 关闭浏览器后，本地cookie立即过期，无法确保上次会话已结束。 上图中的攻击网站可能是指存在其他漏洞的可靠且频繁访问的网站。 因此，对用户来说，登录某个网站后，在不点击几个链接的情况下进行其他操作是难以避免的，随时都有可能成为CSRF的受害者。
CSRF攻击的主要原因是Web的隐式认证机制。 Web验证机制可以保证某个用户的浏览器请求，但不能保证该请求是由用户授权和提交的。
预防CSRF我做过以上介绍。 读者觉得这次攻击很恐怖吗？ 意识到恐惧是件好事。 通过这样做，可以看到下面如何改善，避免出现类似的孔。
CSRF的防御可以从服务器端和客户端两方进行，防御效果比服务器端好，目前一般的CSRF防御也是在服务器端进行。
有几种预防服务器端CSRF攻击的方法，但在思想上是一样的，主要从以下两个方面入手。
1、正确使用GET、POST和Cookie； 2、在非GET请求中添加伪随机数前一章介绍了REST方式的web APP应用，一般情况下，一般的web APP应用以GET、POST为主，另一个请求是Cookie方式。 我们一般按以下方式设计APP。
1、GET用于经常查看、列举、展示等不需要改变资源属性的场合；
2、POST经常下订单，改变一个资源的属性或做其他事情；
下面以Go语言为例，说明如何限制对资源的访问方式。
mux.GET((/user/:uid )、getuser )、mux.POST )/user/:uid )、modifyuser )处理后，修正仅限于开机自检
因此，需要实施第二步骤，在非GET方式的要求中添加随机数。 这个大致分为三种方法。
为每个用户生成唯一的cookie ton，在所有表格中包含同一伪随机值的方案是最简单的。 此方案必须在没有XSS的情况下是安全的，因为攻击者无法获得第三方cookie，表单中的数据在结构上也会失败，但用户的cookie很容易被站点的XSS漏洞窃取。 每次要求使用验证码，这个方案都很完美。 由于要多次输入认证码，用户友好性差，因此不适合实际运用。 不同的表单包含不同的伪随机值。 4.4节介绍“如何防止表格多次提交”时，介绍了该方案。 重用相关代码生成随机数token
h :=md5.New () io.writestring ) h，strconv.formatint(crutime，10 ) ) io.writestring ) h，' ganraomaxxxxx
XXX ' ) Token:=fmt.sprintf(%x '，h.sum(nil ) ) t，_:=template.parsefiles ) ' login.gtpl ' ) t
input type=' hidden ' name=' token ' value=' {.} '验证token
r.parse form (if token :=r.form.get ) ' token ' ) if token！=' ' {//验证Token的合法性}else{//Token无错误}这样基本上可以实现安全的POST，但也许可以说是解读了Token的算法。 理论上是这样，但实际上破解几乎是不可能的。 因为有人计算过。 暴力地解读字符串大约需要2的11次方时间。