Web安全之CSRF
CSRF相较XSS名气小了点,但也是常见安全问题之一,且属于高危漏洞。借着空闲时间,梳理下。
概念
CSRF(Cross Site Request Forgery
),中文意思跨站请求伪造
,是一种冒充受信任用户,向服务器发送非预期请求的攻击方式。
举例
单从概念还是很难理解,那么就以几个例子来辅助理解下。
比如我们收到这样一封邮件,当邮件打开时,写着诱惑性词汇,恭喜你中奖500万,虽然明知道是假的,但是总想点开看一看,万一是真的呢。当我们打开邮件时,发现是骗人的,于是关了。但是殊不知,邮件源码中有这样一段代码,于是当邮件打开时,替换标签IMG就会发起get请求,同时又因为test1.com,我们正常登录过,所以cookie中保存了我们的登陆信息,因此请求成功,我们的ID为123的信息也就删除了。
1 | <img src="https://test1.com/index?action=delete&id=123"> |
为了杜绝这种情况,我们把站点中的删除动作改成post方法,于是以为这样就万事大吉了,但是悲剧还是继续发生了,因为犯罪份子又发了这样一封邮件
1 | <form method="POST" action="https://test1.com/index"> |
打开邮件即中招,看来post也不行,除此之外还有超链接形式或者XHR,这种稍微麻烦点,需要用户主动点击,你不点?如果写了点击就中500万呢。
1 | <a href="https://test1.com/index?action=delete&id=123"> |
以上就是常见的CSRF攻击方式。
分析
由上可以看出CSRF的特征利用用户在A站点的登陆状态及用户未知的情况下,在B站点内发起了访问A站点的请求,从而达到非法目的。
防范手段
基于攻击特征,作出以下的防范措施。为了确保安全,这些方面应该尽可能的做到
- API按照RESTful标准设计,好处是比如删除动作,会是delete方法,那么单纯的链接或者表单下get,post请求无法执行删除操作
- cookie进行Samesite设定,如果是strict,则第三方站点下发起的跨域请求都不会携带cookie,如果是lax,post请求不会携带cookie
- CORS严格控制,这样可以规避跨域异步请求下的一些非法操作
- refer检验,比如上述的Gmail中的请求,完全可以利用refer禁掉
- CSRF Token,一些操作完全也可以增加这样的token,而跨域的脚本无法获得这个token,进而无法攻击
- 关键性Cookie开启SameSite,如果设定为strict,跨站请求不会携带cookie,设定为lax,只有get请求会携带cookie。
写在最后
安全是构建开放Web必须考虑的一环,因此需要重视和采取措施。