阅读 86

【不完全翻译】Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

原文地址:owasp.org/www-project…

业余翻译,少部分章节有删减,并增加了一些个人总结。

简介

CSRF是一种恶意攻击,可能发生在网站、email、博客、讯息或者是一个程序。一旦用户登录过(经过授权),浏览器将执行一些用户意外的操作。CSRF攻击能起作用,是因为浏览器发出的请求自动包含了网站相关的授权认证(credentials),例如用户的cookie、IP地址。因此,如果用户被授权(登录过网站),网站无法区分合法或伪造的请求。我们需要一个攻击者无法获得的token或者标识(identifier),使其不会随着虚假请求被发送。

一个CSRF攻击的影响范围和应用所暴露的漏洞有关。例如,这个攻击可能利用用户的权限进行资金转移、密码更改或进行交易。CSRF攻击会在没有引起用户注意的前提下,通过目标浏览器去执行一些函数。

成功的CSRF攻击影响程度与受害者的权限相关。当攻击一个普通用户,用户数据和相关功能将被暴露;当攻击一个管理员,攻击将会使整个应用陷入危险;使用社交软件,攻击者可以将恶意HTML或js代码嵌入到email或网站中,从而用于给一个特定任务的URL发送请求。攻击任务将直接执行或间接利用XSS漏洞达成。

警告:确保没有XSS漏洞

XSS不是发起CSRF攻击的必须条件。但是却能用于击破CSRF的防范措施(除了下文提到的技术)。 这是因为XSS能使用 XMLHttpRequest简单读取任何网站上的页面 (如果在同一页面中可以直接访问DOM) ,然后从响应中获得token,再在伪造的请求中带上这个token。必须不存在XSS漏洞,以确保CSRF防御不被绕过。

需要注意发生CSRF攻击的地方

以下假设,是在你没有违反RFC2616,section9.1.1规定的前提下提出的。(即:不在GET操作中进行状态改变的操作)。 注意: 如果处于某些原因你在GET请求中进行了修改操作,你必须也要保护这些源头:比如src属性、href属性、form标签(GET方法)。

  • 使用POST请求的form tags
  • Ajax/XHR 调用

CSRF 防御概览

  • 1、基于token的防范措施
    • 抵御CSRF攻击,通常使用token的作为基础防范措施(有状态或无状态的)
  • 2、基于用户交互的防御措施
    • 涉及到高敏操作,还需要使用基于用户交互的保护措施(可以是重鉴权,或one-time token,下文详细展开)
  • 3、纵深防御策略(defense-in-depth )
    • defense-in-depth措施,一般需要配合基于token的防范措施,不可单独使用。

基础防范机制

一、基于token的防范措施

这是应用最广泛的CSRF措施之一。

  • token的2种实现方式:

    1. 有状态的

      同步token模式(synchronizer token pattern)

    2. 无状态的

      基于hash值或加密的token(我们推荐用AES256-GCM来加密, SHA256/512用于HMAC.)

  • 确保遵守2个准则:

    1. 请确保使用足够strong的加密或HMAC函数。注意:你可以选择任何你需要的算法,我们推荐使用AES256-GCM作为加密算法,SHA256/512 用于HMAC。
    2. 确保使用严格的密钥轮换(rotation key);给token设置生效时期。(可以在这里 查看OWASP的通用密钥管理指南)
  • 同步token模式(synchronizer token pattern)

    • 简介

      任何状态改变的操作(如post操作),都需要一个CSRF token。 我们鼓励开发者去使用这种同步token(这种同步token最初的目的是去检测form表单的重复提交)。 同步token的实施,要求生成与当前用户session相关的、随机的tokens。 这些tokens将被插入到form表单、高敏操作的相关调用。 服务端负责去校验token是否存在和准确性。通过将token添加到每个请求,开发者可以保证用户是有正确请求意图的。如果还要完成CSRF攻击,那攻击者必须要知道这个根据受害者session生成的随机token

      注意:这些token不像cookie,cookie会被自动添加到伪造请求中(这些请求由用户的浏览器发出)。这和攻击者能猜出目标受害者的session 标识类似。

    • 如何将token添加到请求中?

      当发起请求的时候,对于form表单,应该将token放入隐藏的input中;ajax请求时,添加到头部 、请求parameter中。token的值必须要是随机的,不能被攻击者猜到。确保token不会被服务端的日志或URL泄漏。一旦CSRF token验证失败,立即拒绝当前请求。

      对于java应用,可以考虑使用java.security.SecureRandom来生成足够长的随机token。可选的 生成算法包括256位 BASE64编码的哈希值。 开发者选择的生成算法必须保证token随机性和唯一性。

      总的来说,开发者只需要为当前session生成一次token。生成token之后,这个值将被存在sessi on里,被用在后续的请求中,直到session过期。 当一个请求被用户直接发出,服务端组件必须要验证token的存在性,并与用户session中的token对比一致。如果不存在,或者token验证不匹配,那么终止请求。

    • “每请求”token (pre-request token)

      如果想进一步提升安全性,可以考虑为每个请求都使用一个随机的CSRF token 参数名 或者 值。 此方法要求生成“每请求”token(per-request tokens),而不是“每会话”token(per-session tokens)。这比“每会话”token要更安全,因为token能被利用的时间范围是最小的。 不过,这可能会引起可用性问题。比如,后退按钮的功能将会失效。因为前一个页面的token不再有效,与上一页的交互将导致服务器上的CSRF误报安全事件。一些应用,比如银行,需要这种高安全性的方法。无论采用何种方法,都鼓励开发人员保护CSRF令牌,就像保护经过身份验证的会话标识符一样,例如使用TLS。

    • CSRF token的特点:

      1. 每个user session都是独立的
      2. 超大随机值,可由CSPRNG生成
      3. 一旦生成,存储在session中,直到session过期
      4. 这些tokens将被插入到HTML表单和高敏服务端操作相关调用。服务端程序负责验证token的存在与正确性。
    • 在头部带上CSRF token 更安全

      使用js在HTTP头部插入CSRF token通常比在form表单中添加隐藏字段更安全。

      在这个情况下,即使CSRF token被泄漏,但是攻击者依旧无法通过直接设置请求头来伪造post请求。

      这是因为,一旦攻击者尝试通过XMLHttpRequest设置任何自定义头部,浏览器将发出OPTIONS(pre-flight)请求。另外,当攻击者尝试使用flash来伪造头部,浏览器将发送一个到crossdomain.xml的get请求。这两种情况,浏览器都能阻止虚假请求被发送。

    • 被URL暴露的token:

      唯一的 per-session token(每session一个token) 在GET请求中将被暴露。GET请求有如下场景可泄漏CSRF token:

      浏览器历史、日志文件、用于记录HTTP请求首行的网络设备、referer头部(如果被保护网站连接到一个外部网站)。 想进一步提升安全性,可以将per-session token 做成per-request(每请求一个token)的。

  • 基于加密的Token模式(Encryption based Token Pattern)

    • token特点:

      这种token主要依靠加密算法的原理,而不是token的比对与验证。它适用于不保存任何状态的服务端。(比如分布式状态下,就更适合使用这种token)

    • token构造:

      服务端使用一个唯一的key,来加密用户的sessionId和时间戳(时间戳为了防止重放攻击,原文replay attacks)。这个token被返回给client,并嵌入到一个隐藏的表单字段,或者在AJAX请求的请求头请求参数

    • token验证:

      一旦接收到请求,服务端读取token,并继续使用创建阶段使用的key来解密token值。如果不能正确解密,意味着是一个攻击请求。解密之后,token里的用户sessionId 和时间戳被验证。sessionId与当前登录(发起请求)的用户session id作比对;时间戳用于与当前时间对比,验证token是否过期。

二、使用标准头部验证origin

  • 原理

    这种防御措施有2步,这2步都依赖于检查HTTP请求头的值。

    • 判断请求的来源。可以通过Origin头或者referer头。
    • 判断请求要去的目标origin。
    • 在server端我们验证这两个值是否匹配。如果他们匹配,则认为这个请求是合理的并接受这个请求(说明是同源请求);如果他们不匹配,我们阻止这个请求(意味这这个请求是跨域的)
  • 可靠性由什么保证?

    因为这些头部不能被程序代码修改(比如使用XSS中的javascript),只有浏览器有权设置他们。

  • 验证来源origin(Source Origin)

    • 通过Origin头部
      如果Origin头部存在,验证它的值是否和目标origin。不像Referer头部,从HTTPS来的HTTP请求(即:https的网站协议降级访问http的链接),将会保留Origin头部。
    • 通过Referer头部
      如果Origin头部不存在,通过判断Referer头的hostname是否和目标origin一致。这个防御方法通常被用于无授权的请求(unauthenticated request),比建立会话(session)前的请求,需要跟踪同步token(synchronization token)
    • 在这两种情况下,确保目标origin检测是完善的。举个例子,如果你的站点是site.com make,请确保site.com.attacker.com不会通过你的origin检测。(进一步说,用origin末尾的/ (斜杠)来保证站点origin的完全匹配)
  • 验证目标origin(Target Origin)

    初步的想法是从请求的URL中去抓取目标origin(hostname和port)。然而,应用的服务器通常经过了一个或多个代理,请求的原始URL一般和真正的服务器URL不同。如果你的应用服务器可被用户直接访问,那么使用URL中的origin是ok的。 你如果有用proxy,有几个选择可以考虑:

    • 在你的应用中,加一些配置以便能够简单地获得目标origin:这是你的应用,因此你可以找到它的目标origin 并在服务端的配置入口简单设置它的值。 这是最安全的方法,因为它由服务端设置,因此是个可信的值。 然而,如果你的应用会被发布到多个地方,比如dev、production、多生产实例,就会由问题了。 为每个情况设置正确的value是困难的,但是如果你可以通过某些中心配置,并让你的应用实例能从中获得值,那就太棒了。(确保这个中心化配置是安全的)
    • 使用Host头部: 如果你更倾向于让应用找到自己的target,那么就不需要为每个发布实例配置target。我们推荐使用Host族的头部。Host头部包含了请求的目标origin。但是你的app服务使用了proxy,Host头部可能会被代理修改,导致和原始请求的URL不同。这个更改,将导致无法与源Origin头部(或Referer 头部)匹配。
    • 使用X-Forwarded-Host头部: 为了解决代理更改host头部问题,我们可以使用另一个头部字段: X-Forwarded-Host。它的目的是为了保存proxy接收到的最原始Host头部值。大部分的代理将会直接转发 X-Forwarded-Host头部保存的目标origin值。因此,你可以使用这个字段,用于和来源origin的作比较。
  • 缺陷:

    • 少部分情况下,Origin头或Referrer头可能不存在(由于某些合法的原因,如保护用户隐私,或者浏览器的问题)

    • 向可信域发送CORS跨域请求,IE11不会增加Origin头部。Referer头部将只保留UI的origin

    • 302 重定向跨域, Origin将不会被包含在重定向的请求头部中,因为它们被认为是敏感信息不能被发送到其他域。

    • 某些涉及隐私的场景下,Origin被设置成“null”(www.google.com/search?q=or…

    • 对于同源请求,Origin头部一般都会带上。但是在大多数情况下,只会被POST/DELETE/PUT这些请求方法带上。如果你在GET请求中,做了一些修改状态的操作,那么这个方法将起不到原作用。

    • Referer 头部也不例外。 负载均衡、代理、嵌入式网络设备都因隐私问题,会导致referrer头部被删除。

三、Cookie的Samesite属性(Samesite Cookie Attribute)

  • 简介:

    SameSite 是一个cookie属性,用于阻止CSRF攻击。在RFC6265bis中被定义。在跨域请求的时候,这个属性帮助浏览器判断是否要发送cookies。可取的值有Lax、Strict和None。

  • 取值:

    • Strict值:

      在所有跨域请求甚至是链接跳转,都不会发送cookie。 比如在github上,一个已登录的用户,在讨论留言板中,点击一个会跳转到github私人项目的链接,那么cookie也不会被发送,无法访问次项目。 对于一些银行站点,任何交易相关的链接都不希望被任何外部站点引用,那么应该使用strict值

    • Lax值(默认值):

      Lax值提供了一个安全与可用性之间的平衡。从外部引用的链接跳转到本站,可以保持用户的登录状态;但是对于有CSRF倾向的post请求,将不会发送cookie。 Lax模式下允许的跨站请求,是最高级别的跳转模式 和同样安全的http请求方法。

    为了增强可靠性,应该配合token使用。

四、双重提交Cookie(Double Submit Cookie)

  • 简介:

    如果在服务端维护CSRF的状态是个问题,那么可以选择使用双重提交cookie。 这个方法简单易行,而且是无状态的。 在这个机制中,我们在cookie里存一个随机值,并同时作为一个请求的参数发送出去。服务端验证cookie里的值是否和请求参数是否一致。

  • 实现:

    用户访问时,站点应该生成伪随机值,并设置在cookie里。每次业务请求都将这个伪随机值提交,可包含在隐藏form表单字段、请求参数、请求头里。服务端来验证是否匹配。

  • 缺陷:

    这个方法,还需要确保子域名是安全的,并且确保都使用HTTPS。 通过双重提交,如果一个攻击者可以写一个cookie,他们就可以打破这个保护机制。写cookie远比 读他们更简单。同源策略规定一个站点的cookie不能被另一个站点访问(原文access)。但是有以下2种情形,跨域访问cookies是可能的:

    a) 子域名可写cookie,且发生XSS攻击

    由于同源策略,虽然 hellokitty.marketing.example.com 无法读取secure.example.com的cookies。但是hellokitty.marketing.example.com可以写父域名 (example.com)的cookie。这些cookies又被secure.example.com 所使用(无法区分cookie被哪个站点使用)。如果XSS发生在hellokitty.marketing.example.com,那么将有可能重写在secure.example.com中使用的cookies。

    b) 中间人攻击

    攻击者是中间攻击者,他们可以使用HTTP强制建立一个请求到相同domain。如果一个应用的host是https://secure.example.com, 即使cookies被设置了安全标志,中间人可以强制建立一个到http://secure.example.com连接,然后重写任何cookies。即使服务器设置了HSTS头部,并且使用的浏览器支持HSTS(这可以阻止中间人发送纯文字的http请求),中间人还是可以简单地给子域名发出一个请求,并重写cookies像a中所述。只有所有子站点都设置了HSTS头部,才是安全的。

    换句话说,只要http://hellokitty.marketing.example.com不强制使用https,攻击者就可以重写example.com subdomain的cookie。

    上面提到的场景a和b能发生,只有当CSRF token没有写到session。因此攻击者可以利用子域名发生的XSS漏洞,来重写父域名的cookie。使token和session(或授权cookie)发生联系(原文:linking token and session/auth cookie),将有助于避免这种漏洞。下面详细介绍:

    • 使用加密算法将cookie加密。

      • 将一个token存到加密的cookie中,而不是一个授权cookie(授权cookie总是被子域名共享)。在服务端通过解密cookie,然后判断得到的token是否与隐藏form表单(或请求头、请求参数)提交上来的token一致。
      • 原理:因为子域名没有父域名用于加密的密钥,因此无法正确重写cookie。
    • 带盐哈希

      • 一个更简单的cookie加密操作是,给token加一点盐来获得hash值(只有服务器端才知道的),然后再把这个token放到cookie
      • 这和加密整个cookie类似(都要求只有服务器掌握某些关键信息,如密钥),但是相比使用加密算法处理cookie,计算量更小一些。使用加密算法或者带盐哈希,攻击者将不能从字面token(plain token)再次构造出正确的cookie值,因为他们不知道服务器的密钥。

五、自定义头部(Use of Custom Request Headers)

CSRF token、双重提交cookie、加密token,或者其他和改变UI相关的防御手段,可能会增加复杂度。 一种适合AJAX/XHR的防御手段,是使用自定义请求头

  • 原理:

    同源策略(SOP)限制:只有同源的js脚本可以增加一个自定义的头部。 默认情况下,浏览器不允许js发出跨域请求。
  • 常用的头有“X-Requested-With: XMLHttpRequest”。因为某些js库已经默认把这个头部加到请求中,如AngularJS。 在这个情况下,你可以简单在服务器端判断这个头部是否存在并验证它的值。
  • 优点:

    • 不需要更改UI
    • 不需要引入服务端状态,更适合REST风格的服务。

你也可以增加你自己的自定义头部。这个防范机制将在4.3节详细介绍(CSRF的健壮防御).

  • 缺陷:

    • 早在2008年就有记录到,使用Flash来绕过防御。在2019年,使用老版本的firefox或者一些近期版本的Chrome也可以利用Flash来绕过防御。我们无法控制浏览器版本,因此这个技术不推荐作为一个基础防范措施。
    • 这种技术对AJAX调用有作用,但是仍然需要使用token来保护form标签。同时,CORS的相关配置也很重要,用于保证这个方法生效(来自外域请求的自定义头部,将触发一个CORS请求预检,原文pre-flight CORS check)。

六、基于用户交互的CSRF防范方法(User Interaction Based CSRF Defense)

前面提到的技术暂时还没有涉及到用户交互,有时跟用户交互相关的防御方法可能更简单也更合适。 以下有几种办法:

  • Re-Authentication (password or stronger)
  • One-time Token
  • CAPTCHA

虽然这是一个很强的CSRF防御,但是对用户体验有影响。对安全要求高的操作(如修改密码、转账),应配合token使用。 请注意,token本身就可以防御CSRF。开发者只有当面对高敏操作、追求更高的安全时,考虑使用这些用户交互相关的防御方式。

七、在AJAX请求头中使用JS自动添加CSRF tokens

下面的指引,默认GET、HEAD、OPTIONS方法都是安全操作。 因此,这三个方法的AJAX调用不需要追加CSRF token头部。 然而,如果这些方法执行了一些状态改变的操作,那么也需要增加CSRF token头部。 POST、PUT、PATCH、DELETE 和 TRACE 方法都是用于改变状态,应该添加CSRF token。

下面给出了一些指引,关于如何重写js库,以便于给每个AJAX请求自动增加CSRF tokens。

  • 在DOM中存储CSRF token的值

    一个CSRFtoken可以被存储在标签中。页面上所有的请求都可以从这个标签中提取出这个CSRF token。它也可以被存在JS 变量或者DOM中的任何地方。但是,它不建议被存在cookies或者local storage中。

    <meta name="csrf-token" content="{{ csrf_token() }}">
复制代码

填充content属性的确切语法将取决于web应用程序的后端编程语言。

  • XMLHttpRequest (Native JavaScript) XMLHttpRequest 的open方法可以被重写,当open方法将被调用时,设置 anti-csrf-token头。下面定义的csrfSafeMethod方法将过滤所有安全方法,并给不安全的HTTP方法添加header
<script type="text/javascript">
    var csrf_token = document.querySelector("meta[name='csrf-token']").getAttribute("content");
    function csrfSafeMethod(method) {
        // these HTTP methods do not require CSRF protection
        return (/^(GET|HEAD|OPTIONS)$/.test(method));
    }
    var o = XMLHttpRequest.prototype.open;
    XMLHttpRequest.prototype.open = function(){
        var res = o.apply(this, arguments);
        var err = new Error();
        if (!csrfSafeMethod(arguments[0])) {
            this.setRequestHeader('anti-csrf-token', csrf_token);
        }
        return res;
    };
 </script>
复制代码
关注下面的标签,发现更多相似文章
评论