CSRF攻击是什么？如何防范？
1、CSRF攻击是什么？如何防范？
CSRF(Cross-site request forgery), 中文名称：跨站请求伪造。攻击者盗用了你的身份，以你的名义发送恶意请求。
CSRF能做的事情包括：以你的名义发送邮件，发消息，盗取你的账号，在受害者不知情的情况下，以受害者名义伪造请求发送给受攻击站点，从而在受害者并未授权的情况下执行受害者权限下的各种操作。
2、CSRF攻击的原理
- 正常网站A,存在CSRF漏洞;恶意网站B含有攻击性代码，用来对网站A进行攻击。
- 正常网站A，有两个用户user01(受害者)和user02(攻击者)。
- user02(攻击者)清楚的了解网站A,并创建了具有攻击性的网站B(钓鱼网站)。
- user01(受害者)登录了网站A后，在自身的session未失效的情况下，访问了恶意网站B.
3、 CSRF攻击的过程
- 1.用户user01通过浏览器访问正常网站A,输入用户名和密码请求登录验证
- 2.登录验证通过后，网站A保存user01的session,并将对应的cookie返回给user01的浏览器。这样user01就可以在网站A执行自身权限下的各种请求(操作)，比如取钱，发表文章，发表评论等
- 3.user01在未退出网站A的时候，在同一浏览器，点击访问了恶意网站B(钓鱼网站)，此时user02拿到user01的认证信息或者登录状态
- 4.网站B是user02创建的，user02清楚的知道网站A的工作模式，网站B通过攻击性代码访问网站A（携带的是user01的cookie)，执行某些并非user01授意的操作。
- 5.网站A并不知道这个恶意请求是从网站B发出的，因此，就会根据user01在网站A中具备的相关权限，执行权限下的各种操作。这样，就在user01不知情的情况下，user02假冒了user01,执行了具备user01用户身份才可以执行的操作
4、CSRF攻击实例
假设，现在有一个受害者Bob，在网站http://bank.expample/有一大笔存款。
Bob通过银行的网站发送请求http://bank.example/withdraw?account=Bob&amount=100000&to=Bob2,Bob将100000的存款转账到Bob2的账户下，通常情况下，该请求发送到银行网站后，服务器会先验证该请求是否来自一个合法的session,该session的用户Bob已经成功登录
黑客Hack自己在该银行也有自己的账户，他知道银行转账操作的URL。Hack可以自己发送一个请求给银行：http://bank.example/withdraw?account=Bob&amount=100000&to=Hack,但是这个请求来自Hack，并非Bob,他不能通过安全验证，因此该请求不会起作用。这时，Hack香到使用CSRF的攻击方式，他先自己做一个网站B,在网站B中放入如下代码：src="http://bank.example/withdraw?account=Bob&amount=100000&to=Hack"，并通过广告等方式诱使Bob访问他的网站。当Bob访问网站B的时候，上述URL就会从Bob的浏览器发向银行，并且这个请求会附带Bob浏览器的cookie一起发现银行服务器。当然，大多数情况下，该请求会失败（session有有效时间），因为银行网站需要要求Bob的认证信息。
但是如果Bob当时恰巧刚访问银行网站后不久，他的浏览器与银行网站的session尚未过期（比如Bob在一个窗口还未退出银行网站），而浏览器中的cookie就含有Bob的认证信息，银行网站的对应session数据还在。
这时悲剧就发生了，这个URL会得到银行服务器的响应，钱将从Bob的账号转移到Hack的账号，而Bob并不知情。等事后Bob发现账户钱变少了，去银行查询流水，却发现是他自己转移账户的钱，没有任何被攻击的痕迹（我搞我自己？人类迷惑行为）
在这个示例中，银行网站错误的认为，这个转账时Bob本人执行的
5、CSRF攻击的对象
从以上的例子可知，CSRF攻击是黑客借助受害者的cookie伪造请求，骗取服务器的信任。黑客所能做的就是给服务器发送伪造请求，改变请求时的参数。所以我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务。则不需要进行CSRF的保护。比如银行系统中转账的请求会直接改变账户的金额，会遭到CSRF攻击，需要保护，而查询余额是对金额的读取操作，不会改变数据，无需保护
6、CSRF漏洞检测
检测CSRF漏洞是一项比较繁琐的工作，最简单的一个方法就是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。
随着对CSRF漏洞研究的不断深入，出现了一些针对CSRF漏洞进行检测的工具，如CSRFTester,CSRE Request Builder等。
CSRFTester工具的测试原理大概是这样的，使用代理抓取我们在浏览器中访问过的所有的连接以及所有的表单等信息，通过在CSRFTester中修改相应的表单等信息，重新提交，相当于一次伪造客户端请求，如果修测试的请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进行CSRF攻击
7、防范CSRF攻击的几种策略
防范原理：防范CSRF攻击，其实本质上就是要求网站能够识别出哪些请求是非正常用户主动发起的。这就要求我们在请求中嵌入一些额外的授权数据，让网站服务器能够区分出这些未授权的请求。比如在请求参数中加一个字段，这个字段的值从登录用户的Cookie或者页面中获取（这个值需要是随机的，无规律可循）。攻击者伪造请求的时候无法获取页面中与登录用户有关的一个随机值或者cookie中的内容的。因此就可以避免这种攻击
目前防御CSRF攻击主要有以下几种策略
-
- 验证HTTP Referer字段
-
- 使用验证码（关键页面加上验证码验证，这种方法对用户不友好，不推荐）
-
- 在请求地址中加入token并验证
-
- 在HTTP头中自定义属性并验证
验证HTTP Referer字段
HTTP头中的Referer字段记录该请求的来源地址。比如访问http://bank.example/withdraw?account=Bob&amount=100000&to=Hack，用户必须先登录http://bank.example,然后通过该网站页面的转账按钮来触发转账事件。这时，该转账请求的Referer值就会是转账按钮所在页面的URL,通常以bank.example域名开头的地址。
而如果黑客要对银行网站实施CSRF攻击，他只能在自己的网站构造请求，当用户通过黑客的网站发送请求到银行网站时，该请求的Referer是指向黑客自己的网站。
因此要防御CSRF攻击，银行只需要对转账请求验证其Referer值，如果以bank.example开头的域名，则说明该请求是来自银行网站自己的请求，是合法的，如果Referer是其他网站的话，则有可能是黑客的CSRF攻击，拒绝该请求。
优点： 简单易行，只需要在最后给所有敏感的请求统一增加一个拦截器来检查Referer的值就可以。特别对于当前现有的系统，不需要改变当前系统已有代码，没有风险，简单便捷
缺点： 这种方法并非万无一失 。首先，Referer的值是由浏览器提供的，但是每个浏览器对不Referer的具体实现会有差别，并不能保证浏览器自身没有安全漏洞。验证Referer的值，把安全性都依赖于浏览器来保障，不安全。而已已有一些方法可以篡改Referer值。另外，用户会因为隐私问题，设置浏览器不允许发送Referer值,这样服务端的Referer验证就没有了意义
在请求地址中添加token并验证
CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户的 cookie来通过安全验证。
要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 中。
可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求
这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对。
对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue 。
而对于 POST 请求，要在 form 表单加上：
<input type=”hidden” name=”csrftoken” value=”tokenvalue”/>
该方法也有一个缺点是难以保证 token 本身的安全。
因为即使是 POST 请求的 token，黑客的网站也同样可以通过 Referer 的值来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。
如果想保证 token 本身的安全，可以考虑使用动态 token，也就是每次请求都使用不同的动态 token。
在 HTTP 头中自定义属性并验证
这种方法也是使用 token 进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到HTTP 头中自定义的属性里。
通过 XMLHttpRequest 对象，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。
通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。
然而，这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 对页面局部的异步刷新。
并非所有的请求都适合用 Ajax 来发起，而且通过该类请求得到的页面不能被浏览器所记录，影响前进、后退、刷新、收藏等操作，给用户带来了不便。
另外，对于没有进行 CSRF 防护的旧系统来说，如果采用这种方法来进行防护，需要把所有请求都改为 XMLHttpRequest 请求，这样几乎是要重写整个网站，工作量无疑是巨大的
