03月20, 2017

关于CSRF攻击

CSRF

简介

Cross-Site Request Forgery(跨站请求伪造);也被称为one-click或者session riding,挟制用户在当前 已经登录WEB应用程序上执行非本意的操作的攻击方法

  1. XSS利用的是用户对指定网站的信任。CSRF利用的是用户对网页浏览器的信任。

How?

简单来说,攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行的一些操作(Email,发小心,甚至财产操作如何转账和购买商品)。由于浏览器曾经认证过,所以被访问的网站会认为是真正的用户操作而且执行。这利用了web用户身份验证的一个漏洞:简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求是用户自愿发出的

Example

假如一家银行用执行转账的URL

http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName

那么恶意攻击者在另外一个网站放置如下代码:

<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">

如果有账户名为Alice的用户访问了恶意站点,而她之前刚访问过银行不久,登录信息尚未过期,那么她将损失1000资金。

这种恶意的网址可以有很多种形式,影藏于网页之中。此外攻击者也不需要放置恶意网址的网址。例如将这种地址隐藏在论坛,博客等任何用户生成内容的网站中。这意味着服务器没有任何防范措施的话,用户即使访问熟悉可信任的网站也有受攻击的危险。

这意味着,攻击者并不能通过CRSF攻击来直接获取用户的账户控制权,也不能直接窃取用户信息。他们所能做到的,是欺骗用户浏览器,以其用户名执行操作。

Defend

检查Referer字段

HTTP的头部有个Referer字段,用以标明请求来自哪个地址,在处理敏感数据的同时,通常来讲。Referer字段应和请求的地址位于同一个域名之下。以银行的操作为例:Referer字段地址通常应该以转账按钮所在的网址,应该也位于同一域名:http://www.examplebank.comz之下。而如果是CSRF攻击传来的请求,Referer字段会出现包含恶意网站的地址。这时候服务器能识别恶意的代码。

  • 这种方法简单易行,工作量低。仅需在关键访问处增加一步校验。

  • 局限性:完全依赖于浏览器发送正确的Referer,虽然该HTTP对此字段的内容有明确的规定,并不保证来访的浏览器的具体实现,也无法保证浏览器没有安全漏洞影响到此字段。并且存在攻击值攻击某些浏览器,篡改其Referer的字段的可能性。

添加token认证

由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址,所以如果要求在访问敏感数据的同时,要求用户浏览器提供不保存在cookie中,并且攻击者无法伪造的数据作为校验,那么攻击者就无法执行CSRF攻击。这种数据通常是一个表单的数据项。服务器将其生成并将它附加在表单中,其内容是一个伪乱数。当客户单通过表单提交时,见这个伪乱数也一并提交上去以供校验。客户端浏览器能够能够正常得到并回传这个伪乱数,通过CRSF传开的欺骗性攻击中,攻击者无法事先得到伪乱数的值,服务器端就会因为校验token为null或错误,拒绝这个可疑的请求。

本文链接:http://inkzhou.com/post/AboutCSRF.html

-- EOF --

Comments