Web 安全之 CSRF 攻击

1. CSRF 漏洞概述

1.1 什么是 CSRF 攻击

• CSRF 被称为跨站请求伪造（Cross-site request forgery）
• CSRF 强制终端用户在当前对其进行身份验证后的 Web 应用程序上执行非本意的操作

1.2 CSRF 攻击对象

• CSRF 攻击的着重点在伪造更改状态的请求，而不是盗取数据
• 因为攻击者无法查看对伪造请求的响应

1.3 CSRF 攻击的场景

• 借助社工的一些帮助
  • 例如通过电子邮件或聊天发送链接
• 攻击者可以诱骗用户执行攻击者选择的操作
• 如果受害者是普通用户，则成功的 CSRF 攻击可以强制用户执行状态更改的请求
  • 例如转移资金，更改其电子邮件地址等
• 如果受害者是管理账户，CSRF 可能会危及整个 Web 应用程序

2. CSRF 关键点

• CSRF 是一种欺骗受害者提交恶意请求的攻击
• 它继承了受害者的身份和特权，代表受害者执行非本意、恶意的操作

3. CSRF 漏洞验证

• 对于大多数站点，浏览器请求自动发送与站点关联的所有凭据
  • 例如用户的会话 cookie，IP 地址，windows 域凭据等
• 如果用户当前已对该站点进行了身份验证，则该站点将无法区分受害者发送的伪造请求和受害者发送的合法请求

4. CSRF 目标

• CSRF 攻击目标是能够更改服务器状态或数据的业务或功能
  • 例如更改受害者的电子邮件地址、密码或购买商品
• 强制受害者查询数据，对于攻击者来说没什么用，因为无法获得服务器响应
• 因此，CSRF 攻击针对引起状态变化的请求

5. 存储的 CSRF 漏洞

• 有时可以将 CSRF 攻击存储在易受攻击的站点上
• 这些漏洞被称为“存储的 CSRF 漏洞”
  • 这可以通过简单的在接受 HTML 的字段中存储 IMG 或 IFRAME 标记
  • 或通过更复杂的跨站点脚本攻击来实现
• 如果攻击可以在站点中存储 CSRF 攻击，则攻击的严重性会被放大
  • 特别是，受到攻击的可能性增加
  • 因为受害者比互联网上的某个随机页面更有可能查看包含攻击的页面

6. CSRF 攻击如何触发

• <a href='转账连接'>大爷! 来玩</a>
• <img src='xxx' alt='渣渣辉，是兄弟就来砍我!'>
• 页面通过<img>标签发送了一个get请求，这个get请求，正是用户发起转账业务的请求

7. CSRF 的类别

• 以上场景中是利用<img>标签发送了一个get请求
• 那么把关键操作使用 post 请求，就能够防御 CSRF 漏洞了吗？答案是否定的

7.1 POST 方式

• 即使转账操作使用 POST 方法，攻击者也可以通过构造表单的方式来伪造请求
• 核心代码如下

<meta charset='utf-8'>
<form name='csrf' action='xxx' method='post'>
	<input type='hidden' name='username' value='hacker'>
	<input type='hidden' name='money' value='1000'>
</form>
<script>document.csrf.submit()</script>
<img src='xxx'><br />

8. CSRF 攻击案例

• 与 XSS 的结合添加后台账号
  • 攻击者可以通过 XSS 来触发 CSRF 攻击，因为可以利用 JS 来发送请求
  • 通过研究受害网站的业务流程，攻击者可以构造如下代码

<script>
xmlhttp = new XMLHttpRequest();
xmlhttp.open(\'post',\'xxx',false);
xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
xmlhttp.send(\'act=add&username=ajest&password=123456&password2=123456&button=%E6%B7xxx&userid=0\');
</script>

• 将代码插入到网站留言板中
• 然后模拟网站管理员，登录后台，进行留言管理，只要管理员刷新页面就会触发 XSS 代码，以管理员的身份发送一个请求，创建一个后台账户[ajest/123456]，同时网站后台管理员一点感觉都没有

9. CSRF 的防御

9.1 无效的防御

• 很多防御方式都没有办法解决 CSRF 的问题

9.1.1 使用秘密 cookie

• 所有 cookie，即使是秘密的 cookie，也会随着每个请求一起提交
• 无论最终用户是否被欺骗提交请求，都将提交所有身份验证令牌、身份凭据
• 应用程序容器仅使用会话标识符将请求与特定会话对象相关联
• 会话标识符不验证最终用户是否打算提交请求

9.1.2 仅接受 POST 请求

• 可以开发应用程序以仅接受用于执行业务逻辑的 POST 请求
• 误解是由于攻击者无法构建恶意链接，因此无法执行 CSRF 攻击
• 但是，有许多方法可以让攻击者欺骗受害者提交伪造的 POST 请求
  • 例如在隐藏值的攻击者网站中托管的简单表单
  • 此表单可以由 JavaScript 自动触发，也可以由认为表单会执行其他操作的受害者触发

9.1.3 多步交易

• 多步交易不足以预防 CSRF ，只要攻击者可以预测或推断完整的事物的每个步骤，就可以实现 CSRF

9.1.4 URL 交易

• 这可能被视为一种有用的 CSRF 预防技术，因为攻击者无法猜测受害者的会话 ID
• 但是，用户的会话 ID 在 URL 中公开
• 所以不建议通过引入另一个安全漏洞来修复一个安全漏洞

9.1.5 HTTPS

• HTTPS 本身无法抵御 CSRF
• 但是，HTTPS 应被视为任何预防措施值得信赖的先决条件

9.2 有效的防御

9.2.1 验证 Referer 字段

• 根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer
• 它记录了该 HTTP 请求的来源地址
• 在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站
  • 比如某银行的转账是通过用户访问 [http://172.16.132.138/bank/action.php?username=hacker&money=1000&submit=%E4%BA%A4...]页面完成
  • 用户必须先登陆，并且访问 [http://172.16.132.138/bank/index.php]
  • 然后通过点击页面上的按钮来触发转账事件
  • 当用户提交请求时，该转账请求的 Referer 值就会是转账按钮所在页面的 URL
  • 而如果攻击者要对银行网站实施 CSRF 攻击，只能在自己网站构造请求
  • 当用户通过攻击者的网站发送请求到银行时，该请求的 Referer 是指向攻击者的网站
  • 因此，要防御 CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值
  • 如果是以 172.16.132.138 的地址或域名，则说明该请求是来自银行网站自己的请求，是合法的
  • 如果 Referer 是其他网站的话，就有可能是 CSRF 攻击，则拒绝该请求

9.2.2 添加 Token 验证

• CSRF 攻击之所以能够成功，是因为攻击者可以伪造用户的请求
• 该请求中所有的用户验证信息都存在于 Cookie 中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的 Cookie 来通过安全验证
• 由此可知，抵御 CSRF 攻击的关键在于
  • 在请求中放入攻击者所不能伪造的信息，并且该信息不存在于 Cookie 之中
• 鉴于此，系统开发者可以在 HTTP 请求中以参数的形式加入一个随机产生的 token（随机字符串）
• 并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求

9.2.3 二次验证

• 二次验证，就是在转账等关键操作之前提供当前用户的密码或者验证码
• 二次验证可以有效防御 CSRF 攻击

9.2.4 用户习惯

• 对于普通用户来说，不学习并具备网络安全知识以防御网络攻击是不现实的
• 但用户养成良好的上网习惯，则很大程度上减少 CSRF 攻击的危害
• 例如
  • 用户上网时，不要轻易点击网络论坛、聊天室、即使通讯工具或电子邮件中出现的链接和图片
  • 及时退出长时间不使用的已登陆账户，尤其是系统管理员，应尽量在登出系统的情况下点击未知链接和图片
  • 用户还需要在连接互联网的计算机上安装合适的安全防护软件，并及时更新软件厂商发布的特征库，以保持安全软件对最新攻击的实时跟踪

10. 总结

• Web 安全第二课
• 对经典的 CSRF 攻击有个大致理解，做个笔记（面试问到了，但是没答上来）