标签: Chrome

谷歌接受批评:新版 Chrome 恢复显示域名中的 www

日前,谷歌为庆祝 Chrome 浏览器10周年,发布了全新的 Chrome 69 正式版,带来了全新的 Material Design 等特性。不过,新版 Chrome 隐藏域名中的 www 遭到了用户批评,并认为会带来安全问题。 Chrome 69 隐藏了网址中的 HTTP/HTTPS,用户随后又发现 Chrome 69 还会隐藏网址中的 WWW,也就是 www.google.com 在地址栏显示的是 google.com。此举引发了争议。WWW 被 Chrome 视为是无关紧要的子域名。但 www.example.com 和 example.com 是有区别的,它们很可能是不同的网站,有着不同的 DNS 记录。Google 的做法被认为会带来安全问题。 对于用户的批评和担心,谷歌坦然接受,并对 Chrome 浏览器作出了更改,在9月12日发布的最新版 Chrome v69.0.3497.92 默认设置中,已经弃用了不再显示协议名称的功能,恢复显示域名中的 www。   稿源:开源中国,封面源自网络;

Chrome 中存在 Wi-Fi 漏洞,谷歌原本并不打算修复

网络安全和渗透测试咨询公司 SureCloud 的研究人员发现谷歌 Chrome 和 Opera 浏览器存在漏洞,可使 Wi-Fi 受到攻击。 研究人员表示,基于 Chrome 内核的浏览器可以保存 Wi-Fi 中路由器管理页面凭据并自动重新输入,以方便用户使用,而由于大多数家用路由器不使用加密通信进行后台管理,这使得研究人员能够利用这种自动凭证重新登录,达到窃取路由器登录凭据并使用它们捕获 Wi-Fi 密码(PSK)的目的。研究人员还提供了一段漏洞利用的演示视频:https://youtu.be/YW0drHztgJY 这个漏洞适用于任何基于 Chrome 内核 Chromium 的浏览器,例如 Chrome、Opera、Slimjet 与 Torch 等,通过明文 HTTP 提供管理页面的任何路由器都会受到此问题的影响。 研究人员早在 3 月 2 日就向 Google 的 Chromium 项目披露了该漏洞,但 Chromium 回复称浏览器功能按设计工作,并且不打算修复。 “安全性和便利性之间始终存在权衡,但我们的研究清楚地表明,存储登录凭据的 Web 浏览器中的功能正在使数以百万计的家庭和企业网络受到攻击“,SureCloud 的网络安全实践总监 Luke Potter 说:“我们认为这个设计问题需要在受影响的 Web 浏览器中修复,以防止漏洞被利用,造成用户损失。”对于谷歌不修复该漏洞的回复,他们也没办法。 而最新消息是,在前两天推出的 Chrome 69 中,谷歌已经修复了该漏洞。   稿源:开源中国,封面源自网络;

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 同时存在的情况下也能发挥作用的补充机制。     稿源:开源中国,封面源自网络;

Chrome 隐身模式可能没有你想得那么能保护个人隐私

据外媒报道,大多数用户在用Chrome上网时都对它的隐身(Incognito)模式抱着合理的期待,但来自行业组织Digital Content Next委托的一项研究结果却呈现了不一样的情况。范德比尔特大学计算机科学教授、研究论文作者Douglas Schmidt指出,如果用户是通过像Gmail等这样的谷歌服务登录,那么从理论上来说即便是在隐身模式下,谷歌还是能通过cookies将用户的浏览情况跟其身份联系起来。 不过如果用户是在登录谷歌账号之前就启动了隐身模式那么跟踪数据就会被清除。 然而这份报告并没有明确指出谷歌是否需要为此负责,但从技术层面上来讲却是可以的。对此,谷歌很快反驳了这种说法。 在一封提供给AdAge的邮件中,谷歌发言人表示并没有把隐身浏览跟用户登录已经退出隐身模式的账号关联起来。另外他还表示,他们的广告系统不会知道Chrome何时处于隐身模式,同时也不知道其他浏览器何时处于类似模式。 这位发言人补充称,这份报告是由一个专业的DC游说团体委托由正与谷歌进行诉讼的一名甲骨文证人撰写。“因此,它包含大量误导信息也就不足为奇了。”   稿源:cnBeta,封面源自网络;

Let’s Encrypt 保驾护航的 HTTPS 网站数量已突破1亿

备受欢迎的安全证书颁发机构 Let’s Encrypt 宣布,当前它已经为超过 1 亿个网站保驾护航,而且这个数字还在持续增长。仅在上个月,使用 HTTPS 保护的站点数量就增加了 2400 万。一天前,Google 刚刚宣布 —— 从 Chrome 68 开始,该浏览器将正式向所有不安全的 HTTP 站点开炮。 在谈到 Let’s Encrypt 和最近的消息时,项目负责人、前 Mozilla 雇员 Josh Aas 表示: 在 Let’s Encrypt 项目推出之前,让每个都启用 HTTPS 是不现实的,毕竟这对财务、技术、教育等方面提出了一定的要求。 我们着力于大规模的易用性工作,这就是近年来部署 HTTPS 的惊人增长的主要推动力。 今天,Let’s Encrypt 签发的加密证书已经覆盖了超过 1 亿个网站,且有望在 2018 年底前达到 1.5 亿+。 Let’s Encrypt 的增长,对业界来说是一个很好的标志性事件。因为它有助于保护人们在登录网站时不被黑客入侵,尤其是那些鱼龙混杂的公共网络。 结合 Google Chrome 突显 HTTP 不安全警告,我们预计可以大幅促进网络上 HTTPS 的增长。 遗憾的是,仍有许多大网站没有即时跟进部署 HTTPS,比如 WhyNoHttps.com 就指出: 中国仍有许多不安全的网站,此外 t.co、wikia.com、bbc.com、foxnews.com、dailymail.co.uk、roblox.com、sberbank.ru、speedtest.net、ladbible.com、ign.com、asos.com 等也不够安全。   稿源:cnBeta,封面源自网络;

Google Chrome 68 正式向所有不安全的 HTTP 网站开炮

在 7 月 24 号发布的 Chrome 68 中,Google 引入了一项重大的变化。当加载非 HTTPS 网站时,该浏览器的处理方式会更加审慎。据悉,只要遇到潜在不安全的站点,Chrome 都将开始抛出警告信息。虽然不会对日常使用造成太大的影响,但这确实是迄今为止发生的一个重大转变。 Chrome 正在改变加载 HTTP 时的处理方法,因为这项老旧的技术未对数据进行加密。   在之前版本的 Chrome 浏览器中,Google 还只是强调“当前访问的网站是否采访用了更加安全的 HTTPS 加密”,并在地址栏上凸显一个标记。 然而现在的情况是,Google 突然加快的步伐,彻底将那些缺失有效安全证书的非 HTTPS 网站划归到了“潜在不安全”的阵营,并抛出安全警示。 在官方支持页面上,Google 解释到: 过去几年中,我们一直主张站点采用 HTTPS,以提升其安全性。去年的时候,我们还通过将更大的 HTTP 页面标记为‘不安全’以帮助用户。 不过从 2018 年 7 月开始,随着 Chrome 68 的发布,浏览器会将所有 HTTP 网站标记为‘不安全’。 简而言之,从 Chrome 68 开始,这一变动将影响到 Web 和内网中‘潜在不安全’HTTP 网站的访问。   稿源:cnBeta,封面源自网络;

Chrome浏览器加固修复幽灵漏洞:内存占用将多出13%

数据显示,Chrome(Chromium内核)浏览器的全球用户量已经超过了10亿,牢牢占据No.1。 不过,Chrome早年一直背负着一个“槽点”,那就是内存占用量高,谷歌为此还做过针对性的优化。 据外媒报道,谷歌本周宣布Chrome浏览器实现了对Spectre(幽灵)漏洞的修复,这个旁路攻击漏洞来自处理器底层,影响包括Intel、AMD甚至ARM平台的大量芯片。 之所以浏览器也要加固是因为漏洞的执行依赖恶意代码加载到本地,而上网传播是最简单直接的方法。 修复了当然是好事,但谷歌软件工程师Charlie Reis确认,这种修复操作将在大型负载下多占用10~13%的运行内存。对于4GB以下的客户来说,绝非一件好事。 据悉,Windows、Mac包括Chrome OS平台的Chrome都在此次“修复”之列。   稿源:快科技,封面源自网络;

Chrome 浏览器页面冻结 bug 死灰复燃 谨防技术支持诈骗套路重演

就当美国人民欢庆独立日的时候,诈骗者们仍未停下他们的脚步。据 Ars Technica 报道,Google Chrome 浏览器中的一个漏洞,竟然再次被骗子们给利用,以传播给不知情的用户。早在 2 月份的时候,Malwarebytes 就警告称,诈骗者正在利用冻结浏览器、同时试图用虚假的报错信息说服用户“给微软打电话”,以忽悠受害者寻找所谓的“技术支持”。 Chromium Bug 追踪器上的一个页面显示,在最初的报告发布后不久,Google 就已经在 Chrome 65 中修复了这个问题。但现在看来,该漏洞似乎又在 Chrome 67 上重现了。 更糟糕的是,随着 bug 的再生,欺诈者们也再次熟练地耍起了同样的伎俩。下图左侧就是欺诈者通过冻结 Chrome 浏览器标签页伪造的报错信息,而右侧可见系统资源被大量消耗。 对于一位在互联网上征战多年的老鸟来说,显然不太可能被这种低级骗术给撂倒: 但与其它类似的弹出式窗口不同,本案例可反复将文件保存到硬盘上,从而快速让浏览器失去响应,以至于无法看到事情的发生。 不幸中招之后,浏览器会被冻结,且用户无法关闭任何窗口。 如果你碰巧遇到了这种情况 —— 无论是不小心访问了一个被黑客入侵的、或是一个带有恶意广告的网站 —— 请记住都不要惊慌、也不要按照所谓的“错误提示”去操作。 只要你拨打了屏幕上显示的这个号码,就会落入预先设置好的诈骗套路 —— 比如索取你的信用卡信息(正经的机构显然不会如此赤裸裸地操作)。 ● 正确的做法是,如果你是 Windows 用户,请通过 Ctrl-Alt-Del 组合键调出任务管理器,然后强制结束 Chrome 浏览器进程。 ● 如果你是 Mac 用户,请使用强制退出(Force Quit)来关闭失去响应的 Chrome 浏览器。 需要指出的是,尽管当前这一漏洞似乎仅影响 Chrome,但 Firefox、Brave、Opera 等浏览器用户也不该掉以轻心。有趣的是,IE 和 Microsoft Edge 两款浏览器竟然对此免疫。 最后,Google 和 Mozilla 都向 Ars Technica 表示,他们正在对此事展开调查。   稿源:cnBeta,封面源自网络;

谷歌新规:禁止从第三方来源安装Chrome扩展程序

新浪科技讯 北京时间6月13日中午消息,之前谷歌决定禁止Windows用户从Chrome网上应用店(Web Store)之外的第三方网站直接安装Chrome扩展程序。而根据谷歌的最新规定,从今年夏天开始,所有平台上的用户都不能从官方应用店之外安装Chrome扩展程序。 谷歌指出,在Chrome网上应用店内有说明资料和功能列表,它们能帮助用户做决定,让他们知道是否真的需要安装某个扩展程序。谷歌发现,如果用户是从官方扩展程序入口进入的,安装附加程序之后卸载的机率更低。 对于2018年6月12日(北京时间13日)发布的扩展程序,谷歌禁止使用“内联式安装”(inline installations)功能。从9月12日开始,现有扩展程序也会禁用此功能。如果用户在网络上其它地方点击链接,只会引导到Chrome Web Store,不能从开发者网站或者其它网站直接安装。 2018年12月初,在Chrome 71浏览器中谷歌会完全删除“内联式安装”功能API,到时开发者再也不能使用该选项。   稿源:新浪科技,封面源自网络;

Google Chrome 将从9月开始,默认 HTTPS 页面为安全站点

据外媒 bleepingcomputer 5月17日报道,谷歌正计划停止在地址栏中标记 HTTPS 页面为“安全”站点,换句话说,在没有发现异常的情况下,所有 HTTPS 的站点都会默认为安全,此举将于今年9月份发布的Chrome 69生效。 Chrome安全产品经理Emily Schechter表示,该公司现在可以通过HTTPS实现这一举措,因为Chrome的大部分流量都是通过HTTPS实现的,因此无需再将用户的注意力吸引到“安全”指标。 相反,Chrome将专注于突出显示用户访问不安全的HTTP网站时的情况。这就是为什么Google将把所有的HTTP网站都标记为“不安全”,这项举措从Chrome 68开始,将于7月发布。 此外,Google计划在Chrome 70中改进“不安全”指标,并增加一项动画,只要用户在 HTTP 网站上的表单中输入数据,就会将“不安全”文本变为红色。 这些更新是Google“HTTPS 100%”计划的一部分,最终目的是让加载到 Chrome 中页面都通过 HTTPS 协议。 “我们希望这些变化能够继续为安全使用网页铺平道路,”Schechter说。 “HTTPS比以往更便宜,更容易,并且可以解锁强大的功能 – 所以不要等待迁移到HTTPS!”   稿源:雷锋网,编译:郭佳,封面源自网络;