A-A+

CSRF 跨站请求伪造 攻击与防御 — CSRF防御策略

2017年12月08日 文章转载 暂无评论 阅读 2,344 views 次

看过程能让你更了解如何的安全编码,看文中红字结果让你知道防范措施。

什么是CSRF 跨站请求伪造

CSRF(Cross-site request forgery),中文名称:跨站请求伪造,也被称为:one click attack/session riding,缩写为:CSRF/XSRF。

那么CSRF到底能够干嘛呢?你可以这样简单的理解:攻击者可以盗用你的登陆信息,以你的身份模拟发送各种请求。攻击者只要借助少许的社会工程学的诡计,例如通过QQ等聊天软件发送的链接(有些还伪装成短域名,用户无法分辨),攻击者就能迫使Web应用的用户去执行攻击者预设的操作。例如,当用户登录网络银行去查看其存款余额,在他没有退出时,就点击了一个QQ好友发来的链接,那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中。

所以遇到CSRF攻击时,将对终端用户的数据和操作指令构成严重的威胁;当受攻击的终端用户具有管理员帐户的时候,CSRF攻击将危及整个Web应用程序。

CSRF 跨站请求伪造的原理

下图简单阐述了CSRF攻击的思想

假如一家银行用以执行转账操作的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资金。

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

透过例子能够看出,攻击者并不能通过CSRF攻击来直接获取用户的账户控制权,也不能直接窃取用户的任何信息。他们能做到的,是欺骗用户浏览器,让其以用户的名义执行操作

因此对于用户来说很难避免在登陆一个网站之后不点击一些链接进行其他操作,所以随时可能成为CSRF的受害者。

CSRF攻击主要是因为Web的隐式身份验证机制,Web的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器,但却无法保证该请求是用户批准发送的。

如何预防  CSRF 跨站请求伪造  (这里推荐了相对安全的防范措施)

过上面的介绍,读者是否觉得这种攻击很恐怖,意识到恐怖是个好事情,这样会促使你接着往下看如何改进和防止类似的漏洞出现(千万不要以为通过更改请求方式例如把Get改为Post请求就可以避免,验证Referer可是可行,但相比如下的验证方式可能更安全一些)。

CSRF的防御可以从服务端和客户端两方面着手,防御效果是从服务端着手效果比较好,现在一般的CSRF防御也都在服务端进行。

服务端的预防CSRF攻击的方式方法有多种,但思想上都是差不多的,主要从以下2个方面入手:

  • 1、正确使用GET,POST和Cookie;
  • 2、在非GET请求中增加伪随机数;

一般而言,普通的Web应用都是以GET、POST为主,还有一种请求是Cookie方式。我们一般都是按照如下方式设计应用:

1、GET常用在查看,列举,展示等不需要改变资源属性的时候;

2、POST常用在下达订单,改变一个资源的属性或者做其他一些事情;

接下来我就以Go语言来举例说明,如何限制对资源的访问方法:


mux.Get("/user/:uid", getuser)
mux.Post("/user/:uid", modifyuser)

这样处理后,因为我们限定了修改只能使用POST,当GET方式请求时就拒绝响应,所以上面图示中GET方式的CSRF攻击就可以防止了,但这样就能全部解决问题了吗?当然不是,因为POST也是可以模拟的。

因此我们需要实施第二步,在非GET方式的请求中增加随机数,这个大概有三种方式来进行:

  • 为每个用户生成一个唯一的cookie token,所有表单都包含同一个伪随机值,这种方案最简单,因为攻击者不能获得第三方的Cookie(理论上),所以表单中的数据也就构造失败,但是由于用户的Cookie很容易由于网站的XSS漏洞而被盗取,所以这个方案必须要在没有XSS的情况下才安全。
  • 每个请求使用验证码,这个方案是完美的,因为要多次输入验证码,所以用户友好性很差,所以不适合实际运用。
  • Get请求也可以考虑验证Referer 来路是否是当前网站。(当然这个方法简单,但不是最安全的方式)
  • 不同的表单包含一个不同的伪随机值,大致实现如下(这里只是举例思路):

生成随机数token


h := md5.New()
io.WriteString(h, strconv.FormatInt(crutime, 10))
io.WriteString(h, "ganraomaxxxxxxxxx")
token := fmt.Sprintf("%x", h.Sum(nil))

t, _ := template.ParseFiles("login.gtpl")
t.Execute(w, token)

输出token



验证token


r.ParseForm()
token := r.Form.Get("token")
if token != "" {
	//验证token的合法性
} else {
	//不存在token报错
}

这样基本就实现了安全的POST,但是也许你会说如果破解了token的算法呢,按照理论上是,但是实际上破解是基本不可能的,因为有人曾计算过,暴力破解该串大概需要2的11次方时间。

这里是对token的建议如果是已登录的界面给予建议:在前端生成含有    用户id|当前时间|当前用户ip   可逆的组合加密项(注意是加密不是编码,切忌不要用base64等常见编码当加密措施),然后后端接收到token然后解密并验证用户ID是否与当前cookie中的用户id一致、用户当前IP是否一致、用户提交的时间与当前时间间隔,如果差距在30分钟以上那么需要用户重新刷新表单提交。

这里解释一下为什么要这么做:首先当用户第一次访问页面的时候,服务端可以获取到用户的ID、用户的当前IP、当前用户访问的时间等一些相关信息,利用这些信息组合做一个可逆向的加密(例如:http://gdd.gd/1531.html),返回给前端,在前端生成一个input  hidden项 name为token,直接放入 value,如果用户执行页面的一些操作Get、Post等请求,会自动带上此值,然后服务端解密此值,然后在与当前获取的同样的数据做判断。

CSRF 跨站请求伪造 总结

跨站请求伪造,即CSRF,是一种非常危险的Web安全威胁,它被Web安全界称为“沉睡的巨人”,其威胁程度由此“美誉”便可见一斑。本小节不仅对跨站请求伪造本身进行了简单介绍,还详细说明造成这种漏洞的原因所在,然后以此提了一些防范该攻击的建议,希望对读者编写安全的Web应用能够有所启发。

文章来源:http://coao.co/2706.html

标签:

给我留言