信安实践——CSRF攻击与防御

1.实验原理

CSRF（Cross-Site Request Forgery，跨站点伪造请求）是一种网络攻击方式，该攻击可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击站点，从而在未授权的情况下执行在权限保护之下的操作，具有很大的危害性。具体来讲，可以这样理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。

简单地说，CSRF攻击就是攻击者盗用了受害者的身份，在存在CSRF漏洞的网站上伪装成受害者进行操作。

CSRF攻击原理

以下介绍涉及4个实体：

• user: 一个普通的互联网用户
• webA: 一个受user信任的网站，但存在CSRF漏洞
• attacker: 利用CSRF漏洞的攻击者
• webB: 攻击者的网站

CSRF攻击步骤如下：

1. user 访问 webA
2. webA 的 cookie 未失效，如 user 未登出 webA，或未清除 webA 的 cookie 等
3. user 访问 webB
4. webB 利用 webA 的 cookie 伪装成 user 向 webA 发送请求
5. webA 接受 webB 的请求，并根据请求携带的 cookie 认为 webB 是 user，执行请求
6. CSRF攻击结束

2.模拟CSRF攻击

首先看一下可以被攻击的页面：

在正常的业务流程中，user（在这是 user 名为 lab3_v）可以在这个页面选择将自己的 zoobars 转移给其他用户，可以理解为极度简化版的银行转账流程。执行这一操作，只需要 user 输入 zoobars 数量和转账用户名。

查看此页面的 html 源代码，我们仅仅需要表单代码，如下：

    
Send  zoobars
    
to 
    

现在一个攻击者attacker，自己构建了一个网站，并且在自己的页面中写下如下代码，假设此页面的URL是 http://csrf.com/csrf.html：

  
    
    
  

  
    

    


        
        
        
    

    
Hi,I'm lab3_a

    
    
  

这段代码主要做的是：将 myzoo.islab.com/transfer.php 的表单页面复制过来，简单修改后将其隐藏，修改的地方主要是每次转移的 zoobars 数量以及转移用户，并在页面加载完毕后使用 js 模拟这个表单提交的事件。这样，就完成了 CSRF 攻击，接下来 attacker 要做的工作就是引导其他用户访问这个页面，只要有某个用户，其在 myzoo.islab.com 的 cookies 还有效，他的 zoobars 就会被转移到 attacker 。
比如，attacker 以用户名 lab3_a 登录 myzoo.islab.com，修改自己的主页的 profile 如下：

click me

之后，如果其他用户，如 lab3_v 访问了 lab3_a 的主页，此时 lab3_v 有 10 个 zoobars， lab3_a 有 10 个 zoobars

之后， lab3_v 点击了 lab3_a 主页上的链接，则 lab3_v 会被引导至攻击页面，并被窃取了 zoobars。

此时 lab3_v 有 9 个 zoobars， lab3_a 有 11 个 zoobars

3.CSRF防御

(1) 验证码

使用验证码，强制用户必须与应用进行交互，才能完成最终请求。在通常情况下，验证码能很好遏制 CSRF 攻击。但是出于用户体验考虑，网站不能给所有的操作都加上验证码。因此验证码只能作为一种辅助手段，不能作为主要解决方案。此外，使用图像识别等方式也可以跳过验证码交互机制。

(2) Referer Check

Referer Check在Web最常见的应用就是"防止图片盗链"。同理，Referer Check也可以被用于检查请求是否来自合法的"源"（Referer值是否是指定页面，或者网站的域），如果都不是，那么就极可能是CSRF攻击。
但是因为服务器并不是什么时候都能取到Referer，所以也无法作为CSRF防御的主要手段。但是用Referer Check来监控CSRF攻击的发生，倒是一种可行的方法。

(3) CSRF Token

现在业界对CSRF的防御，一致的做法是使用一个Token（Anti CSRF Token）。

例子：

1. 用户访问某个表单页面。
2. 服务端生成一个Token，放在用户的Session中，或者浏览器的Cookie中。
3. 在页面表单附带上Token参数。
4. 用户提交请求后， 服务端验证表单中的Token是否与用户Session（或Cookies）中的Token一致，一致为合法请求，不是则非法请求。
   这个Token的值必须是随机的，不可预测的。由于Token的存在，攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性，尽量把敏感操作由GET改为POST，以form或AJAX形式提交，避免Token泄露。

转载于:https://www.cnblogs.com/libaoquan/p/8039434.html