What happens if a browser loads an HTML page like this one?
<html> <head> <title>Test 1</title> <script language="JavaScript"> while(true); </script> </head> <body> </body> </html>
Or this one?
<html>
<head>
<title>Test 2</title>
<script language="JavaScript">
while(true)
alert("free porn movies one click ahead 
");
</script>
</head>
<body>
</body>
</html>
Or this one?
<html>
<head>
<title>Test 3</title>
<script language="JavaScript">
var x = new Array();
var y = x;
while(true) {
y[0] = new Array();
y = y[0];
}
</script>
</head>
<body>
</body>
</html>
You may ask why should one write pages like these?
The first answer is that there are many bad persons in the world, that are just happy to create problems.
The second answer is that there are also good persons that may just insert a bug in a page that results in a piece of code behaving like one of the three up there.
I have tested four browsers: Internet Explorer, Firefox, Chrome, Opera.
Each browser has been updated to the last stable version available at the time of writing. Default options are used.
The test computer is a dual core centrino with one gigabyte of RAM.
Test 1 (infinite loop)
Internet Explorer: it runs the while loop at full speed for less than a second, then a dialog asks if the user want to stop the execution of the script, saying that it is taking too much to complete.
Firefox: a behavior similar to the one of Internet Explorer, but waiting for about 10 seconds, with the application completely blocked (no response to clicks or any other action). The dialog contains a dangerous “don’t ask again option” which could result in a totally blocked Firefox, requiring it to be killed from the task manager.
Chrome: it simply takes a core of the CPU and runs the code forever. The interface of the browser remains perfectly usable, so you can just close the page and continue your life happily. The problem is that there is no notification about the possibility that something is going wrong, i.e. sucking your CPU cycles. Moreover, given that if you open multiple instances multiple chrome processes are created, you can result in killing all the cores of your CPU.
Opera: the same behavior of Chrome, with the difference that Opera runs on a single process and only a core of the CPU is used, independently from the number of instances of the page you open.
Test 2 (alert! alert!)
Internet Explorer: the pop-up dialog hangs the explorer interface, you have to click “Ok” in order to close it and go back to the browser, but then (guess what?) another pop-up comes in the way… The only way to get back in control is to kill the browser from the task manager.
Firefox: exactly the same behavior of Internet Explorer.
Chrome: any pop-up has the option to stop the current page from creating pop-ups, so you are out of the loop in just a click.
Opera: exactly the same behavior of Chrome.
Test 3 (memory attack)
Internet Explorer: this time the browser does not show any dialog notifying the user of the heavy load produced by the page. The browser is completely frozen (but allocating memory), the disk swaps to allocate more memory. I have stopped the mess by killing the process after two minutes and 800 megabytes eaten (and still eating it…).
Firefox: the browser shows the same dialog of test 1, allowing us to stop the memory mess. Unfortunately 870 megabytes have been already allocated and the disk is already swapping. It is interesting to note that Firefox took just few seconds to reach the same amount of allocated memory of Internet Explorer.
Chrome: the script is executed at full speed but once 500 megabytes have been allocated the browser stops it, notifying the user that the script is using too much memory. The interface was perfectly usable at any time during the test.
Opera: the script is executed at full speed AND without memory limit. The system goes rapidly into swapping and the browser stops responding. Killed through task manager after 900 megabytes eaten.
Conclusion
Chrome is the winner of this small test, both for the better design of the alert dialogs, and for the wise limitations to memory use.
It never lose the control of the interface, and this is a very good feature.
The lack of a “heavy load” notification can be explained by the intention of not asking the typical non-expert user to decide on “technical” issues, although I prefer the wait-notify-and-kill option.
The result of this test is globally disappointing, this kind of small Javascript DoS attacks is well know from a long time, and one would not expect that the major browsers are vulnerable to (even one) of them.