Recently, Chrome 92 was released. Let's take a look at a destructive change with great impact mentioned in Chrome 92.
https://www.chromestatus.com/feature/5148698084376576
For iframes from across domains, alert, confirm, prompt and other functions will be disabled.
First, let's take a look at Chrome's official explanation of this destructive motive:
If you don't understand cross domain, you can see my article:
"
At this stage, the JS pop-up window (alert/confirm/prompt) from 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). For example, iframe sites pretend that specific messages are from Chrome (e.g. 1,2,3). By adding "say..." To cover up these deceptions. However, when these alerts come from cross domain iframe, the UI will be more chaotic because Chrome tries to explain that the dialog box does not come from the browser itself or the top-level page. On the one hand, due to the low utilization rate of cross domain iframe JS dialog boxes, from the fact that the main functions of the site usually do not need to use js dialog boxes, on the other hand, it is difficult to reliably explain the source of dialog boxes. Therefore, we recommend deleting JS dialog boxes in cross domain iframe. This will also prevent us from deleting the host name prompt or moving the dialog box to the center of the content area, Make the dialog box more obvious as a part of the page to clarify the meaning of the dialog box (this dialog box is not issued 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 practical demonstration, let's take a look at the effect of the old browser.
Some operators or plug-ins hijack your pages or advertisements and insert elements such as iframe into your pages. 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("Baidu reminder: congratulations on winning the prize!")
</script>
</body>
</html>
Let's simulate this process:
This effect may not be so serious, but it will be used when we use window confirm/window. When prompt is inserted into the page, it is troublesome 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("Baidu reminder: user information is about to expire. Please confirm your password");
console.log(sign);
</script>
</body>
</html>
Perhaps the above two examples are relatively simple, and most people will not be fooled, but if you change to a sub web page with a domain name very similar and more sophisticated means, you can imagine the potential security risks.
Because this problem can be solved when we upgrade Chrome 92.
It can be seen that when an iframe is inserted into the master station, there is a pop-up window, but the master station will not pay attention to this pop-up window at all.
Therefore, when there is a cross domain iframe, its alert/confirm/prompt will fail. This change not only brings security, but also brings many compatibility problems of old systems.
For example, in the internal OA system, some open pages are nested and provided to third-party calls. The page interaction is confirmed by prompt/confirm, so the engineer will make corresponding changes.
<form>
<input type="text" name="name" placeholder="Work order content">
<button id="btn">Submit work order</button>
</form>
<script>
btn.onclick = () => {
const msg = "Are you sure you want to submit?\n\n Please confirm!";
if (confirm(msg) == true) {
axios.post('xxxx')
return true;
} else {
return false;
}
}
</script>
Safety is a double-edged sword. Sometimes it becomes safer and becomes troublesome.
For example, the problem of cross domain requests has driven almost every front-end engineer crazy. Maybe he will complain about why there are cross domains that affect our development?
For another example, similar to the current security authentication, in addition to entering the password, you have to set various security guards, or bind email and mobile phones. All these belong to the security category. Although the product link has become longer for users, it is more secure.