OWASP: 开放式Web应用程序安全项目(OWASP,Open Web Application Security Project)是一个组织,它提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息。其目的是协助个人、企业和机构来发现和使用可信赖软件。开放式Web应用程序安全项目(OWASP)是一个非营利组织,不附属于任何企业或财团。非国内组织,但是国内也在发展该类组织。
一般为两个步骤
所以攻击者在诱骗成功后是可以知道被骗用户可以在该网站执行那些行为。即使请求是被诱导发送的,但是携带了HTTP认证+cookie请求的都会被目标网站视为合法请求。
一般用户向一个网站发送请求的时候,会检查与该网站相关的所有cookie,然后将这些相关cookie一起发送给网站服务端,所以所有发送到该网站的请求都会包含这些cookie。而通常cookie值包含用户的认证信息,并且代表了用户和服务端的会话。本身是用于服务用户体验的,也就是cookie的本地保存可以让用户不必每次访问网页时都进行身份验证。但是这也给CSRF攻击一个契机去获取合法cookie伪造requet请求然后携带自己设计的参数,可能包含一些脚本包括js注入或者其他什么的。
跨站请求伪造攻击仅在受害者已经通过身份验证的情况下进行,因为这样可以直接绕过身份验证,但也正是如此,CSRF也只能通过受害用户拥有的权限去进行攻击,用户无法访问的资源内容CSRF也没有办法去攻击,也就是这些用户没有权限访问的资源在CSRF攻击下是安全可靠的。
HTTP的get请求本质上是一种 幂等 的访问方法,这说明开发web的时候get请求不应该用于修改数据库状态,而只作为一个请求访问或者链接跳转,通俗地讲,发送一个GET请求不应该引起任何数据状态的改变。用于修改状态更加合适的是post方法,特别是对用户信息状态改变的情况。【登录注册都应用post请求】
HTTP/1.1中对幂等性的定义是:一次和多次请求某一个资源对于资源本身应该具有同样的结果(网络超时等问题除外)。也就是说,其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。
简单来说,业务开发中,经常会遇到重复提交的情况,无论是由于网络问题无法收到请求结果而重新发起请求,或是前端的操作抖动而造成重复提交情况,最后应该与只提交一次的所造成的效果和影响相同。
当用户点击攻击者提供的恶意链接后,该恶意网站就会执行一个脚本,引起用户的浏览器发起一个未经受害者统一的请求,受害者用户也不会意识到,在服务端看来该请求就是用户发送的,因为其中包含了验证用户身份的cookie。下面展示通过get请求进行CSRF攻击。
背景:一个有漏洞的服务器希望获得一个get请求去进行转账业务实现。【举例而已】
解释这里为什么用data-fr-src,使用data-src也可以,data-xxx是一种自定义标签,符合H5规范,在img标签中表示懒加载,也就是当有人访问的时候才会自动把data-src中的链接交给src访问。
<img src="" data-fr-src="http://example.com/transfer?amount=1000000&account=Fred" />
一般程序都更愿意使用post请求去改变数据库状态而不用幂等的get请求。post请求的参数在请求体中,因此诱骗受害者发送post请求会更难一些,诱骗受害者发送get请求只需要让用户访问带参的URL即可。使用post请求的时候需要将请求体参数附加到请求中,这就需要在恶意网站中加载有js脚本,当用户访问的时候就触发js脚本,js脚本就会发送一个带有设计好的请求体的请求。
下面展示js脚本:
<body onload="document.csrf.submit()">
<form action="http://example.com/transfer" method="POST" name="csrf">
<input type="hidden" name="amount" value="1000000" />
<input type="hidden" name="account" value="Fred" />
form>
body>
只要恶意网页一加载,就会触发body中的onload事件,运行document.csrf.submit()命令,表示将文档中名为csrf的表单进行submit提交操作。而且input表单框是被隐藏的。
剩下的就和get请求的CSRF攻击一样了,诱骗用户进入恶意网站,网站借用户浏览器发送post请求,服务端认可该post请求,用户丢失100w。
安全专家提出许多防御CSRF攻击的机制,比如使用referer请求头、使用HttpOnly标志、使用jQuery发送X-Requested-With自定义请求头等等。但是这些方法并非适用于所有场景。在某些情况下他们是低效率的。比较高效的实用的是CSRF令牌。
最流行的CSRF防范是使用令牌机制,该令牌与指定的用户相关联,每次接受请求更改表单前服务端会将令牌值作为隐藏值发送给用户,而用户再根据这个即时得到的令牌放进post体里,而攻击者的恶意网站是不可能知道这个令牌的,因为攻击者没办法看到和获取到用户浏览器的响应体,也就是无论攻击者如何设计post请求的CSRF的请求参数,都无法被服务端认为是合法请求,因为不存在令牌匹配。
工作流程:
以上这个流程被称为同步令牌模式。但是还是要注意,就像cookie一样,要在用户登出后一段时间后内令反-CSRF无效。
**新问题:**在ajax请求中,反-CSRF令牌经常作为请求体或请求参数暴露出来
解决:为了使反-CSRF机制有效,它需要进行加密安全处理。【自己加密即可,比如AES加密等,我的上一篇blog有记录如何进行信息加密】
CSRF攻击存在的原因之一是无论在哪个网站对特点服务端发送请求,都会携带对应的cookie参数,比如在恶意网站和用户当前网站发送请求,都会携带cookie,这就给csrf去绕过验证直接使用cookie提供了便利。
同站cookie策略是指,只能在用户当前网站或其延伸网站【同一域名下】发送请求才会携带浏览器相对应的cookie,如果是其他网站或者恶意网站发送请求,请求中是不会存在cookie的。
更详细的解决请看:
Same-origin policy - Web security | MDN (mozilla.org)
同站cookie策略也需要浏览器的支持,而当前只能Chrome和FireFox或者Edge等浏览器支持,并不是所有浏览器都支持。下图是所有支持同站cookie策略的。
因为发起每个请求都将自动携带 cookie,所以 cookie 本身就是一个 CSRF 漏洞。它使得攻击者可以很容易地设计恶意请求并发起 CSRF 攻击。尽管攻击者不能拿到响应体或 cookie 本身,但他们能通过受害者持有的权限执行操作。
CSRF扫描器工具检测:
CSRF Scanner | Acunetix
下面提供几点通用防范CSRF技巧: