-
CSRF
cross site request forgery,跨站域请求伪造。
-
攻击形式
如陌生人给你发qq消息带有链接，点击之后即遭受攻击，你的qq会在你未知的情况下自动向他人或空间中发布小广告等其它攻击者让你发的信息。
-
cookie
cookie是客户在访问web服务器时，服务器在客户磁盘上存放的鉴别用户的信息。
-
原理
当用户访问正常的网站A时，网站A会在你的浏览器端生成你的cookie。（cookie安全级别不高，所以一般浏览器不会把你的密码保存在其中，它会保存你的身份鉴别信息。攻击者想从浏览器中拿到cookie表单是很难的）此时当你点开攻击链接时，攻击网站中一般有如下脚本：
诱导你点开后，你就会携带你的cookie与这个表单去请求服务器，服务器获取cookie中与身份有关的信息，并通过认证，认为你是合法的用户，便把表单中信息发布出去了。
-
防范
分析攻击产生的原因，两个漏洞：
1、发送请求时服务器未进行身份验证
2、服务器不知道请求是主动发送的还是被动的
针对第一种，可以在通信协议中添加一条属性。在HTTP header里有一个Referer值，记录了请求的地址，服务器端只要验证这个请求是否在白名单即可。
但由于这种方法涉及用户隐私，许多用户担心内网中的信息会被泄露到外网，因此安全性不强。
针对第二个问题，从上面的流程可以得知，攻击者无法拿到用户的Cookie，也无法拿到服务器返回的数据（同源策略），他能做的只是伪造用户请求。而上文原因之二在于，服务端难以确定表单是用户主动提交，还是在不自知的时候被动提交的。那么，我们可以在请求中加入攻击者难以伪造的元素。
此时可以使用Token，Token在用户通过验证登入时，由服务器生成返回。Token作为该用户网站进行浏览请求的验证信息。Token可以放在Form或者Header中，这个数据是攻击者在自己的服务器无法伪造的，在使用中，我们往往在中间层部署一个NoSQL类型的数据库，比如Redis来进行存储和验证用户的Token。
但是需要注意的是，对于用户可以随意发布信息的网站，例如论坛，还需要在前端做额外的判断。因为假如攻击者论坛上发布了自己网站诱导用户去点击，此时前端不能携带Token去访问，否则合法用户与他的Token将被攻击者获取，并在自己的服务器建立一张映射表，以此来发起新的CSRF。