上次我们提到了XSS攻击，并说了两种XSS攻击类型，分别是反射型和存储型，并提出了一系列的解决方法。
但是同为程序员的攻击者当然也不会那么轻易被打败，他们很快又找到了一种方式————CSRF
惯例，首先先将定义搬出来
什么是CSRF
CSRF（Cross-site request forgery），中文名称：跨站请求伪造,缩写为：CSRF/XSRF
是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。[from 维基百科]
看到官方定义我们应该会有些疑问
- 能做什么
- 伪造什么
- 怎么伪造
当你了解完这些就明白它与XSS的基本不同点了
能做什么
简单的说，攻击者可以盗用你的登陆信息，以你的身份模拟发送请求。通过一些手段，攻击者就能使用户去执行攻击者的操作。
例如，当用户登录网络银行去查看其存款余额，在他没有退出时，就点击了一个QQ好友发来的链接，那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中。1
2
3
4<!-- 比如银行的get请求长这样 -->
http://www.mybank.com/Transfer.php?toBankId=11&money=1000
<!-- 然后坏人想办法发给你一个链接 -->
<img src='http://www.mybank.com/Transfer.php?toBankId=11&money=1000'>
你最终点击了这个链接，结果就是，你在刚登陆了银行账户的情况下，不明真相的被窃取了1000元到骗纸的账户去了
伪造什么
我们可以通过刚刚那个简单的例子发现，其实它并不像XSS那样，要运行脚本才能进行攻击，它也不需要注入什么东西，甚至不需要获取你的cookie到他那边。
CSRF攻击主要是因为Web的隐式身份验证机制，Web的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的。
简言之，攻击者的最后的目的就是，模仿你本人，给服务端发送请求信息。由于是你自己客户端这边发起的请求，所以服务端以为是你本人的正经请求，所以就帮你处理了，最后造成悲剧。
如何伪造
我们首先要知道，一个`CSRF攻击是如何进行的。
只要两步就可以简单的完成CSRF攻击：
1. 登入受信任网站A，并在本地生成cookie。
2. 在不登出A的情况下，访问危险网站B。
所谓的不登出A，也不是完全是登出了A就安全的，因为你不清楚你的本地cookie是不是关闭了就会马上过期。
接着，危险的网站B，也不一定是攻击者的网站，也可能是可信任的网站，但是有漏洞，然后被人攻击。
在写博客的过程中，看见这样一条新闻
所以说，在遇到CSRF攻击时，将对终端用户的数据和操作指令构成严重的威胁；
当受攻击的终端用户具有管理员帐户的时候，CSRF攻击将危及整个网站的安全。
如何预防
一般的防御方法有以下几种
为用户生成一个唯一的cookie token
所有表单都包含同一个伪随机值——也就是所以当你请求的时候，表单会包含一个随机参数。
因为我们之前强调，CSRF的攻击者并不知道被攻击者的cookie,所以他并没有办法伪造表单的数据，所以这是比较简单的方法
但是这个有个缺点，如果用户的cookie之前被XSS攻击盗取呢，好像也不是100%安全啊。
验证码
相信大家都有在表单上面输入验证码的经历，通过表单的验证码可以很容易判断是不是伪造了请求，而且防御效果还是很好的。
但是有些东西相信大家深有体会的，没错，就是验证码的用户体验是在是不咋滴。
不同的表单包含一个不同的伪随机值
这个随机值token是在前端生成的，通过一系列算法，为每个表单附上不同的随机值。原来是用作防止表单多次重复提交。现在可以稍微修改用作随机添加的token值。而且不需要太担心算法被破解。因为暴力破解该串大概需要2的11次方时间。
主要的实现方法可以参考这篇文章
https能否抵御CSRF
答案是 : 不能
一开始我也以为是可以的，但是其实https是一个加密协议，并不能阻止他攻击的必要两个步骤（1. 登入受信任网站A，并在本地生成cookie。2. 在不登出A的情况下，访问危险网站B）
所以使用https并不能有效的阻止CSRF
