CSRF攻击详解:原理、危害与防护措施
CSRF攻击详解:原理、危害与防护措施
CSRF(跨站请求伪造)攻击是一种常见的Web安全威胁,攻击者通过诱导用户点击恶意链接,利用用户已登录状态下的Cookie信息,向目标网站发送恶意请求。本文将详细介绍CSRF攻击的原理、危害及多种有效的防护措施。
漏洞介绍
CSRF(Cross Site Request Forgery)中文名称为跨站请求伪造,攻击者诱导用户点击特定链接触发恶意请求,服务端没有校验请求是否来自授信站点,误将恶意请求视为合法请求并成功执行。漏洞充分利用HTTP协议的无状态特性,即登录态Cookie信息是浏览器默认自动携带的,通过浏览器发送HTTP请求时,浏览器将携带该域名所属Cookie信息一并发送到服务器。与XSS相比,XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来攻击受信任的网站。
漏洞危害
攻击者通过QQ、微信、钉钉等聊天软件向受害者发送恶意链接,诱导用户点击链接进入攻击站点(有些伪装成短域名),执行恶意操作,如以受害者名义发送邮件、更改个性化配置、购买物品、转账汇款等。
攻击场景
漏洞典型攻击场景说明如下:
- 用户登录站点A,浏览器存储 cookie信息。
- 站点A的cookie信息处于有效期内,用户使用同一款浏览器以标签页形式访问危险网站B。
- 诱导用户点击站点B内某些资源,在用户不知情的情况下,在站点B内发送恶意请求(携带站点A的Cookie信息)至站点A。
- 站点A的CSRF 防御措施不健全,服务端没有验证请求是否由授信站点发出,直接根据Cookie信息的合法性处理该请求,导致站点A成功执行来自站点B发出的恶意请求。
防护措施
防护措施对比说明
CSRF防护措施主要包括HTTP Rerferer验证、Token校验、验证码校验、安全配置header属性等,其具体说明如表1所列:
表1 CSRF防护措施优缺点对比
验证HTTP Referer
Referer字段记录了请求来源地址,可使用该字段校验请求是否来自安全站点,阻止非授权站点内触发的恶意请求,如果Referer为第三方非授权网址或空,一定程度上可判断该请求为恶意请求。相关典型问题如表2所列:
表2 Referer校验典型问题说明
例如,使用nginx的ngx_http_referer_module模块校验"referer"字段,阻止非允许域名发出的请求,具体参考配置如下:
验证码校验
针对账户交易、预留手机号码修改、密码修改等业务场景,可在页面交互设计中增加验证码(包括短信验证码、图形验证码),在用户在提交重要操作时,用户需输入验证码信息。服务端接到API请求后并完成对验证码的校验。通常验证码可以很好地防御CSRF攻击,但可能影响用户体验,系统也不能将所有重要操作增加验证码校验。因此,验证码校验只能作为一种辅助手段,仅在关键核心业务操作中使用。
Token验证
关键交易携带攻击者无法获取到的Token,服务端校验Token的合法性,具体步骤如下:
- 用户打开页面,服务器生成一个Token,在提交API报文时,不能将Token存放在Cookie中了,否则又会被攻击者冒用。
- 在该页面内提交的API请求报文中添加Token。
- 服务端接收到包含Token的API请求后,需判断Token的有效性,校验不通过的请求直接异常返回。
以POST方式提交报文
如果关键交易API选用GET方式,则很容易被利用发起CSRF攻击,如在HTML页面内构造img标签,自动触发恶意请求。推荐关键交易API采用POST方式,可提高CSRF攻击成本,攻击者需在第三方页面(攻击站点)内构造POST请求,诱导用户首先进入预先准备好的攻击站点,并触发恶意请求,增加攻击链路长度。同时,用户可通过第三方页面域名识别站点是否为安全站点,降低恶意链接点击率,避免进入攻击站点。
安全设置SameSite属性
安全设置Samesite属性,保护cookie信息不被非授权网站利用,可设置属性为Strict/Lax/None,具体说明如下。
- Strict最为严格,浏览器将禁止第三方Cookie,即跨站点访问时,第三方站点发送的请求均不会携带本域Cookie。
- Lax相对宽松,大多数情况下不允许发送第三方cookie,但是导航到目标网址的GET请求除外。
- 使用None的话,跨站访问时将携带本域Cookie信息发送至服务端。
总 结
以上是CSRF攻击的常见防护方法,应用系统结合业务特点选择合适防护措施等,并安全设置SameSite属性。同时也可使用WAF(Web应用防火墙)监视、过滤危险请求,提高系统安全性。