Recently, Chrome 92 was released. Let’s take a look at a destructive change with a relatively large impact mentioned in Chrome 92.
https://www.chromestatus.com/feature/5148698084376576
For cross-domain iframes, functions such as alert, confirm, and prompt will be prohibited.
First, let's take a look at Chrome's official explanation of this destructive motive:
If you don’t understand cross-domain, you can read my article:
"
At this stage, the JS pop-up window (alert/confirm/prompt) derived from the iframe (whether cross-domain or not) is confusing because it looks like the browser's own pop-up window when it appears. This container deceives users (especially window.prompt), such as iframe sites pretending that certain messages come from Chrome (such as 1, 2, 3). Cover up these deceptive behaviors by adding "<hostname> say..." before the message. However, when these alerts come from a cross-domain iframe, the UI will be more confusing, because Chrome tries to explain that the dialog does not come from the browser itself or the top-level page. On the one hand, due to the low usage rate of the cross-domain iframe JS dialog box, from the fact that the main functions of the site usually do not need to use the JS dialog box, on the other hand, it is difficult to reliably explain the source of the dialog box. Therefore, we recommend deleting the cross-domain iframe JS dialog box. JS dialog in domain iframe. This will also prevent us from deleting the hostname prompt or moving the dialog box to the center of the content area to make the dialog box more obvious as part of the page to clarify the meaning of the dialog box (this dialog box is not sent by the browser) ). Therefore, when a cross-domain iframe pop-up window (alert/confirm/prompt) appears, it will be blocked, otherwise these child iframes may pretend to be the dialog box of the parent page.
"
For the actual demonstration, let's take a look at the effect of the old version of the browser.
Some operators or plug-ins hijack your page or advertisement, and insert some iframe and other elements into your page. Take alert as an example:
// localhost:5000
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
<script>
alert("百度提醒：恭喜中奖！")
</script>
</body>
</html>Let's simulate this process:
This effect may not be so serious, but it will window.confirm/window.prompt to insert into the page, because they are exchangeable.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
</head>
<body>
<script>
const sign = prompt("百度提醒：用户信息即将过期请确认你的密码");
console.log(sign);
</script>
</body>
</html>
Perhaps the above two examples are relatively simple, and most people will not be fooled, but if you switch to a sub-page with a very similar domain name and more sophisticated methods, then the security risks can be imagined.
Because when we upgraded Chrome 92, this problem was solved.
It can be seen that when an iframe is inserted into the main site, there is a pop-up window inside, but the main site simply does not care about the pop-up window.
Therefore, when there is a cross-domain child iframe, its alert/confirm/prompt will be invalid. While this change brings security, it also brings a lot of compatibility issues with the old system.
For example, in the internal OA system, some open pages are nested and provided to third parties to call, and the page interaction is prompt/confirm , then the engineer must make corresponding changes.
<form>
<input type="text" name="name" placeholder="工单内容">
<button id="btn">提交工单</button>
</form>
<script>
btn.onclick = () => {
const msg = "您真的确定要提交吗？\n\n请确认！";
if (confirm(msg) == true) {
axios.post('xxxx')
return true;
} else {
return false;
}
}
</script>Security is a double-edged sword, and sometimes it becomes more troublesome when it is safer.
For example, the issue of cross-domain requests has made almost every front-end engineer mad, and they may complain about why there is such a thing as cross-domain that affects our development?
For another example, similar to the current security verification, in addition to entering a password, you must also set up various secrets, or bind emails, mobile phones, and the like, all of which belong to the security category, although the product link has become for users It's longer, but it's safer.
back at the author’s previous highly praised articles, you may be able to gain more!
- 2021 front-end learning path book list-the road to self-growth
- Talking about the front-end watermark from cracking a design website (detailed tutorial)
- takes you to unlock the mystery of "File Download"
- 10 kinds of cross-domain solutions (with ultimate big move)
Concluding remarks
+Like+Favorite+Comment+
Pay attention to the notes of the Qiufeng, a front-end public account that focuses on front-end interviews, engineering, and open source
chrome
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。