Chrome|Chrome 92 破坏性功能,我这弹窗有何用()
近期,Chrome 92 进行了发布,我们来看看 Chrome 92 中提及的一个影响比较大的破坏性改动。
https://www.chromestatus.com/...
文章图片
对于来自跨域的 iframes 将被禁止 alert、confirm 和 prompt 等功能。首先我们先来看看 Chrome 对这个破坏性的动机的官方解释:
如果不明白跨域的可以看我这篇文章:
"
现阶段来源于 iframe(不管是否跨域的) 的 JS 弹窗(alert/confirm/prompt)是令人困惑,因为它出现的时候看起来像浏览器自己的弹窗。 这容器欺骗用户(尤其是 window.prompt),例如 iframe 站点假装特定消息来自 Chrome(例如 1,2,3)。通过在消息前加上 " say..." 来掩饰这些欺骗行为。 然而,当这些 alerts 来自跨域 iframe 时,UI 会更加混乱,因为 Chrome 试图解释对话框不是来自浏览器本身或顶级页面。 一方面由于跨域 iframe JS 对话框的使用率较低,从事实来看,站点的主要功能通常不需要使用 JS 对话框时,另一方面难以可靠地解释对话框的来源,因此我们建议删除跨域 iframe 中的 JS 对话框 。 这也将避免我们将通过删除主机名提示,或者将对话框移动到内容区域的中心,来使对话框更明显地成为页面的一部分来明确对话框的含义(这个对话框不是由浏览器发出的)。因此当出现跨域iframe 弹窗(alert/confirm/prompt)将会被阻止,否则这些子 iframes 可能会假装父页面的对话框。
"
为了实际的演示,我们先来看看旧版浏览器的效果。
文章图片
有些运营商或者插件劫持你的页面或者广告,会往你的页面插入一些 iframe 之类的元素。以
alert
为例:// localhost:5000
Document - 锐客网
我们来模拟一下这个过程:
文章图片
这个影响可能没那么严重,但是会使用当我们使用
window.confirm/window.prompt
来插入到页面的时候,可就麻烦大了,因为他们是可交换的。
Document - 锐客网
文章图片
也许以上两个例子比较简单,绝大多数人都不会上当,但是如果换成一个域名非常相似,手段更加高明的子网页,那么其中的安全隐患可想而知。
文章图片
因为当我们升级了 Chrome 92 之后,这个问题便得以迎刃而解了。
文章图片
可以看到,当往主站中插入一个 iframe ,里面是有弹窗的,但是主站根本不会理会这个弹窗。
因此当存在跨域的子 iframe ,它的
alert/confirm/prompt
将会失效。这个改动带来安全性的同时也带来了很多老系统的兼容性问题。例如内部的 OA 系统,就是嵌套一些开放性的页面提供给第三方调用,页面交互就是以
prompt/confirm
进行确认的,那么工程师就要进行相应的改动了。
【Chrome|Chrome 92 破坏性功能,我这弹窗有何用()】安全是一把双刃剑,有些时候更安全了,就会变得麻烦。
例如跨域请求问题,几乎曾让每个前端工程师都抓狂过,也许还会抱怨为什么还有跨域这种东西来影响我们的开发的?
再比如,类似于现在的安全验证,除了输入密码,还得设置各种密保,或者绑定邮箱啊手机啊类似的种种,都是属于安全范畴,虽然对用户来说产品的链路变得更加长了,但是它更安全了。
回看笔者往期高赞文章,也许能收获更多喔!
- 2021前端学习路径书单—自我成长之路
- 从破解某设计网站谈前端水印(详细教程)
- 一文带你层层解锁「文件下载」的奥秘
- 10种跨域解决方案(附终极大招)
关注公众号
秋风的笔记
,一个专注于前端面试、工程化、开源的前端公众号文章图片
推荐阅读
- Mac安装Chromedriver
- www和https://又被Chrome地址栏隐藏了
- 《暗黑破坏神2(重制版》应是一款新游戏,因为暴雪弄丢了源代码)
- Don't|Don't Make Me Think 原则在Chrome中的应用
- Chromium|Chromium 禁止用户删除内置搜索引擎给开发者带来新”困扰“,后续(“该功能将在 Chrome 98 / 99 中恢复”)
- chrome插件教程终-使用vue来开发chrome插件
- chrome插件教程5-了解csp网站安全策略
- chrome插件教程3-自定义页面和入口
- chrome插件教程4-处理页面和入口之间的通信
- chrome插件教程2-一个简单的chrome扩展