记一个frida调试瑞幸的过程

0x00 起因

Chrome缓存和CORS这个文章里记录的Chrome缓存存在问题,在Access-Control-Allow-Origin:* 且Access-Control-Allow-Credentials: false的情况下可能可以获取到敏感信息(credentials可能是true也行),

0x01 前提

先说一下关于这两个头部值的一些问题:

  1. Access-Control-Allow-Origin:*时,credentials不能设置为true,设置为true可能会报错?(不确定),可以设置为false,设置为false不报错,不设置默认应该也是false,即允许任何域时不允许ajax请求传递敏感头部
  2. Access-Control-Allow-Origin: 某域名时,credentials设置true则是常见的配置漏洞,设置为false时浏览器如果发起ajax时设置withcredentials为true则报错
  3. 当不设置时默认为null,即拒绝除本域以外所有的域名

    0x02 想法

    如果文中所说的属实,那么这个漏洞存在应该很久了,而且利用条件很低,目测只要有敏感接口并且设置了Access-Control-Allow-Origin:*,那么这个接口就变成了一个在Chrome浏览器下接近于csrf漏洞。
    比较一下这个漏洞和jsonp、csrf的差别:

    jsonp

    得存在callback的jsonp接口,存在这种接口,并且会根据cookies返回敏感信息,因为script标签会传递cookies所以就变成了csrf,防范手段也和csrf类似,但接口必须是支持jsonp格式的json接口

    一般csrf

    一般的csrf通常是构造html表单并自动提交,通常是触发特定动作而不能获取到数据

    这个缓存漏洞

    一般的通过js去拉取数据需要cors配置为Access-Control-Allow-Origin: 某域名且credentials设置true,利用该第三方域名可控来获取敏感数据,但如果配合Chrome缓存问题,可以把这个origin扩大到任意域名,但有个潜在的条件是需要用户先访问目标接口后缓存了页面数据,才可以读取该接口的返回数据。换句话说利用条件:
  4. 没有csrf防御
  5. 存在敏感信息或有利用价值的东西
  6. origin为星号
  7. 用户在这之前用Chrome浏览器访问过该接口