CSRF漏洞原理攻击与防御

CSRF（Cross-site request forgery）跨站请求伪造：也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。

与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。

csrf漏洞的成因就是网站的cookie在浏览器中不会过期，只要不关闭浏览器或者退出登录，那以后只要是访问这个都网站，会默认你已经登录的状态。而在这个期间，攻击者发送了构造好的csrf脚本或包含 csrf脚本的链接，可能会执行一些用户不想做的功能（比如是添加账号等）。

CSRF可以做什么？

你这可以这么理解CSRF攻击：

攻击者盗用了你的身份，以你的名义发送恶意请求。

CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......

造成的问题包括：个人隐私泄露以及财产安全。

想要深入理解CSRF的攻击特性我们有必要了解一下网站Session的工作原理。

Session大家都不陌生，无论是用.net还是PHP开发过网站的程序员都肯定用过Session对象，然而 Session它是如何工作的呢？如果我们把浏览器的Cookie禁用了，大家认为Session还能正常工作吗？答案是否定的。

在这里举个简单的例子帮助大家理解Session。比如我买了一张高尔夫俱乐部的会员卡，俱乐部给了我一张带有卡号的会员卡。我能享受哪些权利呢？如果我是高级会员卡可以打19洞和后付费喝饮料，而初级会员卡只能在练习场挥杆。我的个人资料都是保存在高尔夫俱乐部的数据库里，我每次去高尔夫俱乐部只需要出示这张高级会员卡，俱乐部就知道我是谁了，并且为我服务了。　因此我们的高级会员卡卡号相当于保存在Cookie的Sessionid；而我的高级会员卡权利和个人信息就相当于服务端的Session对象。

我们知道Http是无状态的协议，它不要求浏览器在每次请求中标明客户端自己的身份，并且浏览器以及服务器之间并没有保持一个持久性的连接用于多个页面之间的访问。为了维持web应用程序状态的问题，每次Http请求都会将本域下的所有Cookie作为Http请求头的一部分发送给服务端，服务器端就可以根据请求中的Cookie所存放的Sessionid去Session对象中找到该会员资料了。

我们理解了Session的工作机制后，CSRF也就很容易理解了。CSRF攻击就相当于攻击用户复制了我的高级会员卡，然后攻击用户就可以拿着这张假冒的高级会员卡去高尔夫俱乐部打19洞，享受美味的饮料，而我这个受害者在月底就会收到高尔夫俱乐部的账单。

CSRF原理:

CSRF攻击过程有以下两个重点：

1.目标用户已经登录了网站，能够执行网站的功能

2.目标用户访问了攻击者构造的URL

1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

2.在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；

4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C 的权限处理该请求，导致来自网站B的恶意代码被执行。

了解CSRF的机制之后，危害性我相信大家已经不言而喻了，我可以伪造某一个用户的身份给其好友发送垃圾信息，这些垃圾信息的超链接可能带有木马程序或者一些欺骗信息（比如借钱之类的），如果CSRF 发送的垃圾信息还带有蠕虫链接的话，那些接收到这些有害信息的好友万一打开私信中的链接就也成为了有害信息的散播着，这样数以万计的用户被窃取了资料种植了木马。整个网站的应用就可能在瞬间崩溃，用户投诉，用户流失，公司声誉一落千丈甚至面临倒闭。曾经在MSN上，一个美国的19岁的小伙子 Samy利用CSS的background漏洞几小时内让100多万用户成功的感染了他的蠕虫，虽然这个蠕虫并没有破坏整个应用，只是在每一个用户的签名后面都增加了一句“Samy 是我的偶像”，但是一旦这些漏洞被恶意用户利用，后果将不堪设想，同样的事情也曾经发生在新浪微博。

相关举例：

受害者Bob 在银行有一笔存款，通过对银行的网站发送请求 “http://bank.example/withdraw?account=bob&amount=1000000&for=bob2”可以使 Bob把1000000 块的存款转到Bob2的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的Session，并且该Session的用户Bob已经成功登陆。黑客Hacker自己在该银行也有账户，他知道上文中的URL可以把钱进行转帐操作。 Hacker可以自己发送一个请求给银行： http://bank.example/withdrawaccount=bob&amount=1000000&for=Hacker。但是这个请求来自Hacker而非 Bob，他不能通过安全认证，因此该请求不会起作用。这时，Hacker想到使用CSRF的攻击方式，他先自己做一个网站，在网站中放入如下代码： src=“http://bank.example/withdrawaccount=bob&amount=1000000&for=Hacker”，并且通过广告等诱使 Bob 来访问他的网站。当Bob访问该网站时，上述URL就会从Bob的浏览器发向银行，而这个请求会附带Bob浏览器中的 Cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求Bob 的认证信息。但是，如果Bob当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的Session尚未过期，浏览器的Cookie之中含有Bob的认证信息。这时，悲剧发生了，这个URL请求就会得到响应，钱将从Bob的账号转移到Hacker的账号，而Bob当时毫不知情。等以后Bob发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而Hacker则可以拿到钱后逍遥法外。

CSRF检测:

检测CSRF漏洞是一项比较繁琐的工作，最简单的方法就是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。随着对CSRF漏洞研究的不断深入，不断涌现出一些专门针对CSRF漏洞进行检测的工具，如CSRFTester，CSRF Request Builder 等。以CSRFTester工具为例，CSRF漏洞检测工具的测试原理如下：使用CSRFTester进行测试时，首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息，然后通过在CSRFTester中修改相应的表单等信息，重新提交，这相当于一次伪造客户端请求。如果修改后的测试请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进行CSRF攻击。

CSRF防御:

目前防御 CSRF 攻击主要有三种策略：

验证 HTTP Referer 字段；
在请求地址中添加token并验证；
在HTTP头中自定义属性并验证。

验证Referer

根据 HTTP 协议，在HTTP头中有一个字段叫Referer，它记录了该 HTTP 请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如需要访问

http://bank.example/withdraw?account=bob&amount=1000000&for= Hacker，

用户必须先登陆bank.example，然后通过点击页面上的按钮来触发转账事件。这时，该转帐请求的 Referer值就会是转账按钮所在的页面的URL，通常是以bank.example域名开头的地址。而如果黑客要对银行网站实施 CSRF 攻击，他只能在他自己的网站构造请求，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站。因此，要防御CSRF攻击，银行网站只需要对于每一个转账请求验证其Referer值，如果是以bank.example开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果Referer是其他网站的话，则有可能是黑客的CSRF攻击，拒绝该请求。

这种方法的显而易见的好处就是简单易行，网站的普通开发人员不需要操心CSRF的漏洞，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查Referer的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。

然而，这种方法并非万无一失。Referer的值是由浏览器提供的，虽然 HTTP协议上有明确的要求，但是每个浏览器对于Referer的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。事实上，对于某些浏览器，比如 IE6 或 FF2，目前已经有一些方法可以篡改 Referer值。如果 bank.example网站支持 IE6 浏览器，黑客完全可以把用户浏览器的Referer值设为以bank.example域名开头的地址，这样就可以通过验证，从而进行 CSRF 攻击。

<?php
header("Content-type:text/html;charset=utf-8");
// 如果没有token, 怎么保证请求是合法的呢？
// 请求头里面有一个字段： referer, 专门用于记录请求来源
// http://www.s285.com/csrf/referer.php
$referer_conf = "http://www.s285.com/csrf/referer.php";
// 获取请求过来的referer
$request_referer = $_SERVER['HTTP_REFERER'];
// 对referer进行对比
if ($referer_conf != $request_referer){
die("请求不合法！");
}
echo "进来啦！";
// 有些浏览器，是不会自带referer的，还有一些浏览器referer可以修改。
// 就会造成一些问题，referer判断不准确

添加token:

CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于Cookie中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的Cookie来通过安全验证。要抵御CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于Cookie之中。可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。这种方法要比检查Referer要安全一些，token可以在用户登陆后产生并放于session之中，然后在每次请求时把 token从session中拿出，与请求中的token进行比对，但这种方法的难点在于如何把token以参数的形式加入请求。对于 GET 请求，token将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenv alue。而对于 POST 请求来说，要在 form 的最后加上这样就把 token 以参数的形式加入请求了。

表单令牌:

<?php
header("Content-type:text/html;charset=utf-8");
// 开启session
session_start();
// 在配置文件里面有一个key
$key = "qwaerfewasfasfadgkljdgslkdfjiadfjads";
// 生成token
$token = md5(rand(1, 100000).$key);
// 存放到session中
$_SESSION['token'] = $token;
?>
<form action="./edit_back.php" method="post">
<label>姓名：</label><input type="text" name="username">
<br><br>
<label>年龄：</label><input type="text" name="userAge">
<br><br>
<label>地址：</label><input type="text" name="userAddress">
<input type="hidden" name="token" value="<?=$token?>">
<br><br>
<input type="submit">
</form>

后台验证：

<?php
header("Content-type:text/html;charset=utf-8");
// 开启session
session_start();
// 获取表单的令牌
$token = $_POST['token'];
// 获取session中的token
$session_token = $_SESSION['token'];
echo $token."~~~".$session_token;
// 判断令牌
if ($token != $session_token){
die('提交的数据有问题！');
}
echo "修改成功！";

自定义属性进行校验jwt: Json web token主要是用于前后端分离的项目。

CSRF核心是借COOKIE,XSS核心是偷COOKIE

怎么防止别人借用COOKIE？怎么才能不让别人借COOKIE？所有的和认证信息相关的一些数据，都不存放在COOKIE中，　全部放在请求头Authorization这个字段中。这个字段（Authorization）里面存放的就是：用户ID，用户的角色........ JWT: 会对传输的数据进行加密，如果要解密，需要服务端私钥的。就算JWT被劫持，被修改，在服务端校验的时候依然通不过