标签: cookie

Cookie 机制问题多 Chrome 工程师提出改造方案

日前 Chrome 工程师 Mike West 发表了一篇文章提议改造 Cookie 标准,以强化 HTTP 状态管理。Mike 分析了目前 Cookie 存在的几个方面的问题,包括很难安全使用、浪费用户资源,以及隐私问题,通过它可以以令人惊讶的方式跟踪用户在网络上的活动。   关于浪费用户资源,Mike 解释,服务器可以为一个注册域名存储大量 Cookie,并且很多 Cookie 可以通过 HTTP 请求发送。例如 Chrome 允许为每一个域名存储大约 180 个 Cookie,相当于约 724kB 数据。在众多 Cookie 中,其请求头大小的中位数是 409 字节,但是其中却有 90% 有 1589 字节,95% 占了 2549 字节,99% 甚至达到了 4601 字节,另外有约 0.1% 的 Cookie 头非常大,超过了 10kB。如此滥用,效率低下。 隐私方面,众所周知 Cookie 可以用于身份验证,但它同时也可以用来悄悄跟踪用户的相关信息。 而关于安全使用的难处,Mike 列出了几条在开发中安全使用 Cookie 遇到的问题: Cookie 对 JavaScript 默认是可用的,这使得一次 XSS 可以获取持久凭证。虽然十年前引入了 HttpOnly 属性,目前也只有大概 8.31% 的人使用 Set-Cookie 进行相应设置。 默认情况下,Cookie 会被发送到非安全的源,这会导致凭据被盗。Secure 属性虽然可以标记安全的 Cookie 源,但目前只有大概 7.85% 的人使用 Set-Cookie 进行了设置。 Cookie 经常在请求发送者毫不知情的情况下被发送。SameSite 属性可以减少 CSRF 风险,但是目前只有大概 0.06% 的人使用 Set-Cookie 进行了设置。 Mike 认为,一方面 Cookie 采用的缓解安全问题的属性很差,Cookie 根本不符合我们决定对其它类型的 Web 可访问数据强制执行的安全边界。它们在给定的可注册域中流过源,它们忽略端口和方案,这意味着它们可以被网络攻击者轻易伪造,并且它们可以缩小到特定路径,这些特征使得它们难以推理,并制定激励措施来削弱平台其它部分的同源策略。 Mike 给出了一套新方案,他解释,用户代理可以通过为用户访问的每个安全源生成唯一的 256 位值来控制它代表用户表示的 HTTP 状态,此 Token 可以作为结构化 HTTP 请求头传递到源: Sec-HTTP-State:token = * J6BRKagRIECKdpbDLxtlNzmjKo8MXTjyMomIwMFMonM * 此标识符或多或少类似于客户端控制的 Cookie,但有一些值得注意的区别: 客户端控制 Token 的值,而不是服务器。 Token 只能用于网络层,而不能用于 JavaScript(包括类似网络的 JavaScript、例如 Service Workers)。 用户代理每个源只生成一个 256 位 Token,并且只将 Token 暴露给生成它的源。 不会为非安全源生成或传递 Token。 默认情况下,Token 将与同一站点请求一起提供。 Token 一直存在,直到服务器、用户或用户代理重置为止。 在些基础上,将为开发人员提供一些可通过 Sec-HTTP-State-Options HTTP 响应头触发的控制点,有如下选项: 1、某些服务器需要跨站点访问其 Token,其它服务器可能希望将交付范围缩小到同源请求,服务器可以指定任一选项: Sec-HTTP-State-Options: ..., delivery=cross-site, ... 或者: Sec-HTTP-State-Options: ..., delivery=same-origin, ... 2、某些服务器希望限制 Token 的生命周期,可以允许它们设置 TTL(以秒为单位): Sec-HTTP-State-Options: ..., ttl=3600, ... 时间到期后,Token 的值将自动重置。同时服务器也可能希望明确触发 Token 的重置行为(例如,在注销时),这可以通过设置 TTL 为 0 来实现: Sec-HTTP-State-Options: ..., ttl=0, ... 在任何一种情况下,都可以向当前运行的页面通知用户的状态变化,以便执行清理操作。当发生重置时,用户代理可以将消息发送到名为 http-state-reset 的源的 BroadcastChannel(并且可能唤醒源的 Service Worker 以响应用户驱动的重置): let resetChannel = new BroadcastChannel('http-state-reset'));resetChannel.onmessage = e => { /* Do exciting cleanup here. */ }; 3、对于某些服务器,客户端生成的 Token 足以维持状态,它们可以将其视为不透明的会话标识符,并将用户的状态绑定到服务器端。其它服务器需要额外的保证,他们可以信任 Token 的出处,为此,服务器可以生成唯一密钥,将其与服务器上的会话标识符相关联,并通过 HTTP 响应头将其传递给客户端: Sec-HTTP-State-Options: ..., key=*ZH0GxtBMWA...nJudhZ8dtz*, ... 客户端将存储该密钥,并使用它来生成某些数据集的签名,从而降低 Token 被捕获的风险: Sec-HTTP-State: token=*J6BRKa...MonM*, sig=*(HMAC-SHA265(key, token+metadata))* Mike 同时也表示,该方案并不是一个完全与 Cookie 不同的新东西,并不是要在目前替换掉 Cookie,虽然弃用 Cookie 是应该的,但是当下该方案只是提出了一种在 Cookie 同时存在的情况下也能发挥作用的补充机制。     稿源:开源中国,封面源自网络;

普林斯顿信息中心( CTTP )发现浏览器“自动填充”漏洞最新玩法

据外媒 12 月 27 日报道,普林斯顿信息技术政策中心( CTTP )发现了利用浏览器“自动填充”漏洞窃取用户信息的最新玩法。目前,所有浏览器的登录管理器都存在着一种设计缺陷 ——登录管理器允许浏览器记住用户在每个特定网站上的用户名和密码,并在用户再次访问该网站时自动将其插入到登录表单。正是因为登录管理器的这种工作方式,网络追踪者可以在加载追踪脚本的网站上嵌入隐藏的登录表单,以便窃取用户信息。 普林斯顿隐私专家警告说,广告和分析公司利用登录管理器的漏洞设置隐藏的登录字段秘密提取网站用户名,并绑定未经身份验证的用户的个人资料或电子邮件访问该网站。 安全隐私专家称这种漏洞已存在十多年,仅在 XSS(跨站点脚本)攻击期间搜集用户信息。不过目前恶意人士已设计了新的攻击方式。 据悉,普林斯顿研究人员于近期发现了两种利用隐藏登录表单收集登录信息的网络跟踪服务:Adthink (audienceinsights.net) 、 OnAudience (behavioralengine.com)。这两种跟踪服务利用其脚本搜集了在 Alexa Top 100 万网站列表中发现的 1110 个网站的登录信息。目前登录信息只包含了用户名或电子邮件地址 ,并没有涉及到重要的密码信息。 鉴于这种情况,广告公司和分析公司通过窃取的用户名/电子邮件创建一个散列,并将该散列与网站访问者的现有广告配置文件绑定。研究人员介绍,电子邮件地址的散列是一个良好的跟踪标识符。因为电子邮件地址是唯一的、持久的,并且用户的电子邮件地址几乎不会改变,清除 cookie、使用隐私浏览模式、或者切换设备都不会阻止跟踪。网络追踪者可以通过电子邮件地址的散列来连接分散在不同浏览器、设备和移动应用程序上的在线配置文件。此外,该散列还可以作为 cookie 清除之前和之后浏览历史记录配置文件之间的链接。 知情人士透露,除了 Brave 浏览器之外,其他主流浏览器似乎都容易受到这种类型的攻击,例如基于 Chromium 的浏览器在用户点击页面时披露用户密码。研究人员目前已提出解决方法:厂商将浏览器设置为仅在用户与实际需要登录的字段交互时再自动填充即可。 根据普林斯顿的说法,秘密收集用户数据不仅限于侵犯了个人用户的隐私,实际上可能也违反了欧盟即将实行的 GDPR 法规,即使有些网站所有者并不清楚其行为属于跟踪范畴。 相关阅读 普林斯顿信息技术政策中心(CITP)提供的演示页面 消息来源:Bleeping Computer,编译:榆榆,校审:FOX; 本文由 HackerNews.cc 编译整理,封面来源于网络。 转载请注明“ 转自 HackerNews.cc ” 并附上原文链接。

黑客伪造 WordPress 核心域名、非法窃取 Cookie 数据

据外媒 10 日报道,安全公司 Sucuri 发现黑客利用一系列恶意软件将恶意代码注入合法 JavaScript 文件,伪装 WordPress 核心域名、窃取 cookie 数据及非法收集用户信息。 据悉,黑客通过误植域名( Typosquatting )或劫持 URL 技术制造虚假域名,而该技术通常依赖于用户在网络浏览器中错误输入 URL 。由于伪造网站被设计成一个看似合法的 WordPress 域名,所以代码显示并无异常。 调查显示,该恶意代码的条件语句并不包括搜索引擎抓取工具中用户代理的 cookie 数据,旨在帮助黑客从抓取工具与机器人中筛选出有价值 cookie。据悉,一旦确定数据有效,该脚本就会将其发送至恶意网站( code.wordprssapi [.] com )。此外,黑客除了在 WordPress JavaScript 文件底部注入恶意代码以外,还利用另一个 WordPress 漏洞注入混淆代码、恶意离线 WordPress 网站 。 研究人员表示,目前尚且无法确定恶意网站幕后黑手,而黑客在权限被撤销之前可以伪装用户执行权限内任何操作。在此,有必要提醒网站管理员除审核网站代码外还需仔细检查网站域名以确保不向第三方发送敏感数据(如 cookie 或密码)。 原作者:Chris Brook, 译者:青楚,译审:游弋 本文由 HackerNews.cc 翻译整理,封面来源于网络。 转载请注明“转自 HackerNews.cc ” 并附上原文链接