One of the more notorious problems you might run into when using a computer is a browser hijacking attack, where stumbling upon a maliciously crafted Web site will result in an alert being repeatedly displayed, regardless of how many times you try to close it. While you might resort to force-quitting Safari to overcome this problem, with Apple’s “Resume” feature in OS X, when you re-launch the browser your Web pages will load again, resulting in the same frustrating behavior.
The classic approach to fixing this issue is to remove the saved window state of Safari, which can be done by manually trashing the saved application state folder for Safari from your user library, or by launching Safari with the Shift key held down. The problem with this is that the rest of your workflow will be closed, which can be frustrating if you had many windows and tabs open. Granted you can use options in the History menu to re-open windows from the last session, but this may open the malicious Web page and have you back where you started.
At its core, this issue comes from how browsers have classically handled Javascript alerts–a feature intended for brief use to notify a user of a problem or quick result, and then be dismissed. Unfortunately, Javascript alerts demand user feedback (clicking an OK button, or otherwise) before they will close, and in the mean time all other browser functions become inaccessible. By simply looping a Javascript alert, you can cause this problem to occur, and it can be done with essentially beginner knowledge of the Javascript language.
Sequential alerts from the same Web page will show this option, to dismiss any additional alerts and thereby save your browser from a Javascript hijack attack.
Despite this setback that has affected most browsers, in the latest versions of Safari, Apple has included an easy solution to this problem. With a small tweak to the Javascript runtime in Safari, if a page displays Javascript alerts in rapid succession, the alerts will include a checkbox that offers the option to stop showing alerts from the current page. This will effectively kill the hack, and allow you to close the offending page.
Note that there is a caveat to this, which requires you also have Safari’s option to block popup windows enabled (toggled in its Security preferences). Without this feature enabled, a Javascript alert attack could trigger Safari to open the current page in a new window, resulting in another instance of the page triggering the same error, so by clicking the “OK” button to dismiss the problem, you will be flooded with new windows and alert boxes. Even with the option to prevent additional alerts from these pages, you may still find that a crafty page could continue to burden you in this manner, but by disabling popup windows, and by installing the latest versions of Safari on your Mac, you will effectively shut down this frustrating Javascript hack.
Be sure this option in Safari’s Security preferences is checked, to prevent pages from issuing the same Javascript error.
As of this writing, the latest version of Safari is version 9.0, which is available as a public beta version for testing. This can be obtained by enabling pre-release software in the App Store system preferences, and then checking for updates in the App Store. Overall, simply keeping Safari and OS X up to date should make these options available to you.
If you care to test your current browser, clicking the following button will load two alerts from this page, the second of which will have the checkbox to prevent additional alerts if your version of Safari supports this feature. If not, then consider looking into updating Safari.
No Youtube audio using 8.0.8 (10600.8.9). How to fix it besides “Developer – User Agent – Safari 7.1.8”?
On the other hand, this forum forgets the email and username, besides not being possible to edit posts. It would be great if that could be fixed. BTW, Thanks for the great site.
I meant Safari 8.0.8 (10600.8.9). Cannot edit post above.
Before this change I would break the loop by disabling javascript in the Develop menu in the intervals between dismissing the alert and its re-appearance.
For the heck of it, I tried your two alerts with Firefox – my preferred browser. The first time I just looked at the two alerts, did not check the box in the second alert. Then I did it again and checked the box. On the third try, there were no alerts. Interesting. Then I tried it with Safari and checked the box right away and again – no more alerts. And I am still using Mt. Lion, so my Safari is version 6.2.8 – just updated a few days ago. Thanks.
One similar situation that is specific to Safari is when a web page is loaded with HTML5 Canvas fingerprint images and you choose NOT to let them track you. I ran into this today at a BBC news webpage that offered five images on the page, all using Canvas code to potentially fingerprint visitors to the page. In the past, I’ve only run into pages with a single Canvas fingerprinting image. But when a page serves up a barrage of Canvas fingerprinting images, it can be daunting. I had to go through Safari’s, thankfully built-in, anti-Canvas fingerprinting dialog for all five images. I wondered if I was experiencing a new browser hijack JavaScript attack. But no. Eventually, I was able to read the page with none of the offending Canvas images showing up.
My expectation is that with time, HTML5 Canvas fingerprint images are going to be used with great regularity whereby several on a single web page may become a new norm. In response, Apple is going to have to alter their dialog from having users block each individual Canvas fingerprinting image to instead a dialog blocking Canvas fingerprinting for the entire page in one go. I expect Apple with catch on to this problem soon. Meanwhile, I’ll be sending Apple ‘bug’ reports about the matter and hope other’s running into this problem will as well.
Article needs to be updated; the second to last paragraph talks about enabling pre-release software in App Store System Preferences, but that option does not exist in a default install of the OS unless you’ve (manually) enrolled with Apple’s Beta Software program: https://beta.apple.com/sp/en/betaprogram/faq
I suggest noting the offending URL, perhaps copying it to the clipboard, and then using either the free Hosts 0.13 system preference panel or Gas Mask.app you can block this domain forever in every web browser with an entry like 127.0.0.1 . There is also the free ScamZapper but that works only within Safari.
Topher, the technique worked with your links in Safari Version 7.1.8 (9537.85.17.9.1) in Mavericks. It’s worth noting that there is a different version of Safari for each iteration of OS X. At a guess, Safari 9 is for El Capitan, which makes it irrelevant for Mavericks and Yosemite users – and every other version of OS X as well. Which makes your suggestion to download Safari 9, beta or otherwise, pretty useless for anyone not running the El Capitan beta.
Since, as with Karen vB, the links you provide work in another version of Safari on my Mac, and in Firefox on hers, it suggests your information about this being a Safari 9 feature is inaccurate. Or that there is something wrong with your test code. I’ll leave it to you to figure out which is the case.