CSRF

此过滤器可以用来防止基于路由或虚拟主机设置的跨站点请求伪造。简单来说,CSRF 是这样一种攻击方式:恶意的第三方利用漏洞,使得他们可以仿冒用户提交非正常的请求。

在章节 1 的 对跨站点请求伪造的强大防御 中有一个真实的例子:

“例如,在 2007 年末[42],Gmail 有一个 CSRF 漏洞。当 Gmail 用户访问恶意站点时,恶意站点能够为 Gmail 生成一个请求, Gmail 将其视为与受害者进行持续会话的一部分。在 2007 年 11 月,一位网站攻击者利用此 CSRF 漏洞向 David Airey 的 Gmail 账号[1]中注入了电子邮箱过滤器。”

有很多种方法来减轻 CSRF 攻击,有一些已经在 OWASP 预防备忘单 罗列出来了。 此过滤器采用了一种称之为来源验证的无状态减轻攻击模式。

此种模式依赖以下两条用于确定请求是否来自同一个主机的信息: * 导致用户代理发布请求的源(请求源)。 * 请求将要发送到的源(目的源)。

当过滤器评估一个请求时,必须确保上述信息都是存在的,且要比较它们的值。如果请求源缺失或者来源不匹配,则请求被拒绝。例外的情况是,如果请求源被视为有效且已经被添加到了策略中。因为 CSRF 攻击专门针对状态改变的请求,因此过滤器仅对具有状态改变方法(POST、PUT 等)的 HTTP 请求起作用。

Note

由于各浏览器之间的功能不尽相同,此过滤器将通过信息头部来决定请求的来源,如果这些信息不存在,它将会返回请求头部引用中主机和端口的值。

关于 CSRF 的更多信息,可参与下面页内容。

配置

CSRF 过滤器支持扩展能力,用来扩展它认为有效的请求源。它之所以能够做到这一点,且同时又能减轻了跨站点 请求伪造的企图的原因,在于 front-envoy 应用过滤器时已经达到了目的源。这就意味着虽然端点可能支持跨源请求, 但它们依旧受到保护,以避免那些不被允许的恶意的第三方的攻击。

需要注意的是,请求通常应该来自与目标相同的来源,但有些用例可能做到这一点。比如,你正在第三方供应商上托管了一个静态网站,但是又需要因追踪目的发出一些请求。

Warning

其他的来源可以是精确的字符串、正则表达式、前缀字符串或者后缀字符串。当添加正则表达式、前缀或后缀来源时, 建议谨慎行事,因为不明确的来源可能会造成安全漏洞。

运行时

可以通过 filter_enabled 字段中的 runtime_key 值来配置启用过滤器的请求占比。

可以通过 shadow_enabled 字段中的 runtime_key 值来配置仅在影子模式下启用过滤器的请求占比。仅当在影子模式下,过滤器将评估请求的 OriginDestination 来决定它是否是有效的,但是不会强制执行任何策略。

Note

如果同时开启了 filter_enabledshadow_enabled,则 filter_enabled 标记位会优先起作用。

统计

CSRF 过滤器输出的统计信息在 <stat_prefix>.csrf.* 命名空间下。

名称

类型

描述

missing_source_origin

Counter

请求源头部缺失的请求总数。

request_invalid

Counter

请求源和目的源不匹配的请求总数。

request_valid

Counter

请求源和目的源匹配的请求总数。