漏洞公告团结互助，让我们共同进步！

当前位置：主页 > 技术资讯 > 网络安全 > 漏洞公告 >

我们的优势： 10年相关行业经验，专业设计师量身定制设计师一对一服务模式，上百家客户案例！企业保证，正规流程，正规合作 7*24小时在线服务，售后无忧

SOP（同源策略）绕过漏洞：Keybase的CORS策略错误配置，可以操纵浏览器缓存获取用户敏感数据信息

文章来源：重庆网络安全围观次数：

分享到:

摘要：由于通过CORS（跨域资源共享）机制启用了Keybase io使用的多个API端点，这种缓解同源策略的机制在某种程度上克服了同源策略的严格限制，允许不同域服务器实施交互式请求。

由于通过CORS（跨域资源共享）机制启用了Keybase.io使用的多个API端点，这种缓解同源策略的机制在某种程度上克服了同源策略的严格限制，允许不同域服务器实施交互式请求。 Keybase的CORS策略配置错误。使用此缺陷，可以操纵浏览器缓存来获取用户敏感的数据信息。

Keybase是一个开放源代码，跨平台的即时消息工具，它支持PC设备上的macOS，Linux和Windows平台，并提供Chrome / Firefox浏览器扩展。也适用于iOS和Android。与许多IM 工具相比，Keybase最吸引人的功能是它可以免费使用，并且不会受到任何广告骚扰。最重要的是，它也是一个开源项目。

在安全性和隐私性方面，Keybase使用端到端加密，并承诺为每个用户的组，文件和聊天数据提供安全保护。如果此数据上传到云，它也将被加密。

前言

当前用户向其他用户发送加密消息时，Keybase允许当前用户通过API接口找到其他Keybase用户。此接口提供例如公共密钥和发送加密消息所需的其他Keybase用户信息。

该API接口的CORS（跨域资源共享）策略配置如下：

Access-Control-Allow-Origin: *

Access-Control-Allow-Methods: GET

Access-Control-Allow-Headers: Content-Type, Authorization, Content-Length, X-Requested-With

Access-Control-Allow-Credentials: false

在理解此CORS配置问题之前，让我们澄清一些要点：

1. Access-Control-Allow-Origin中的星号“ *”表示任何外部域名都可以与API交互并执行跨域请求调用；

2. Access-Control-Allow-Credentials中的“ false”描述，出于安全原因，服务器不允许用户在跨域请求中包括代表身份信息的cookie。这里的Access-Control-Allow-Headers公开的用户身份验证标头信息与下面将描述的漏洞无关，因为在查询上述API接口时未使用该信息。

漏洞情况

自然地，由于上述可查询的API接口是公共的，因此在进行跨域请求时，无需携带令牌信息来防止CSRF（跨站点请求伪造），因为使用Keybase.io以及其会话时对用户进行了身份验证信息存储在cookie中。仅某些非常敏感的API接口将要求用户身份验证标头token包含在请求标头中。

如果在消息加密验证和发送过程中使用API查找其他Keybase用户以找到自己，即使我只输入首字母，我的某些帐户信息也会在搜索结果中匹配，其中包含我的一些敏感信息，例如：

电子邮件地址

我使用并保留的邀请代码数

计费信息

上次登录的时间戳，电子邮件中的时间/日期验证码

TripleDes加密的PGP私钥

经过测试后，在上述API请求中删除了Cookie信息后，个人敏感信息将不再显示。但是在服务器对API的响应消息中找到了名为“ Etag”的消息标头。这是浏览器缓存标签头，这意味着客户端的资源请求没有更改，因此浏览器可以下载请求以检索缓存的内容并响应用户。

Payload和漏洞利用

Twitter用户@Bitk_使用了一种技巧，该技巧使用javascript的fetch API方法直接从浏览器缓存中强制执行跨域请求，并且碰巧Keybase在此处未在服务器响应标头上部署任何缓存控制头（Cache-Control）措施，因此在本地构造了以下Payload

<html>