JavaScript Editor JavaScript Debugger     JavaScript Editor 



Team LiB
Previous Section Next Section

Browser Security Problems with JavaScript

JavaScript has a long and inglorious history of atrocious security holes. Unconvinced? Fire up your favorite browser, head to your favorite search engine, and search for “JavaScript vulnerability”—you should find tens of thousands of results. Of course, this is not an indication of the exact number of security holes in browsers, but it does give a rough idea of the magnitude of the problem. Such vulnerabilities range from relatively harmless oversights to serious holes that permit access to local files, cookies, or network capabilities.

But security problems with JavaScript are not limited to implementation errors. There are numerous ways in which scripts can affect the user’s execution environment without violating any security policies.

Bombing Browsers with JavaScript

The amount of resources a browser is granted on the client machine is largely a function of its operating system. Unfortunately, many operating systems (including Windows 95 and 98) will continue to allocate CPU cycles and memory beyond what may be reasonable for the application. It is all too easy to write JavaScript that will crash the browser, both by design and by accident.

The content of the next several sections is designed to illustrate some of the main problems browsers have with denial-of-service attacks, with the “service” in this case being access to an operating system that behaves normally. The results will vary from platform to platform, but running any one of these scripts has the potential to crash not only the browser but also your operating system itself.

Infinite Loops

By far the most simplistic (and obvious) way to cause unwanted side effects is to enter an infinite loop, a loop whose exit condition is never fulfilled. Some modern browsers will catch and halt the execution of the most obvious, but seldom would they stop something like this:

function tag() 
{
   you_are_it();
}
function you_are_it()
{
   tag();
}
tag();

Infinite loops can arise in a variety of ways but are often unstoppable once they have begun. While most infinite loops eat up cycles performing the same work over and over, some, like the preceding one, have a voracious appetite for memory.

Memory Hogs

One of the easiest ways to crash a browser is to eat up all the available memory. For example, the infamous doubling string grows exponentially in size, crashing many browsers within seconds:

var adiosAmigo = "Sayanora, sucker.";
while (true) 
   adiosAmigo += adiosAmigo;

You can also fill up the memory that the operating system has available to keep track of recursive function calls. On many systems, invoking the following code will result in a “stack overflow” or similar panic condition:

function recurse() 
{
   var x = 1;    
    
   // you can fill up extra space with data which must be pushed 
   // on the stack but mostly we just want to call the function
   // recursively
   recurse();    
}

You can even try writing self-replicating code to eat up browser memory by placing the following in a <<script>> in the document <<head>>:

function doitagain() 
{
   document.write("<<scrip" + "t>>doitagain()<</scrip"+"t>>");
}
doitagain();

Using the Browser’s Functionality

A popular variation on the theme is a script that writes <<frameset>> elements referencing itself, thereby creating an infinite recursion of document fetches. This prevents any user action because the browser is too busy fetching pages to field user interface events.

Similarly, you can open up an endless series of dialog boxes:

function askmeagain()
{
   alert("Ouch!");
   askmeagain();
}

or continually call window.open() until the client’s resources are exhausted.

Deceptive Practices

The ease with which developers can send browsers to the grave is only the tip of the iceberg. Often, deceptive programming tactics are employed to trick or annoy users in one way or another. One of the most common approaches is to create a small, minimized window and immediately send it to the background by bringing the original window into focus(). The secondary window then sets an interval timer that spawns pop-up ads on a regular basis. The secondary window comes equipped with an event handler that will blur() it when it receives focus and an onunload handler to respawn it in the unlikely event that the user can actually close it.

In Chapter 21, we briefly discussed a technology found in Internet Explorer 5+ known as DHTML Behaviors. Behaviors have very powerful capabilities, including the ability to modify browser settings. The simplest example of deceptive use of DHTML Behaviors is attempting to trick a user into changing the default home page of his/her browser:

<<a onclick"this.style.behavior'url(#default#homepage)';
this.setHomePage ('http://www.example.com')" href="">> 
Click here to see our list of products!
<</a>>

Often sites will pop up windows or dialog boxes disguised to look like alerts from the operating system. When clicked or given data, they exhibit all manner of behavior, from initiating downloads of hostile ActiveX controls to stealing passwords. Typically, these windows are created without browser chrome and when created skillfully are nearly indistinguishable from real Windows dialog boxes. Some researchers have shown how to carry out even more clever attacks with chromeless windows. A carefully created window can be positioned so as to perfectly cover the browser’s Address bar, making it appear as if the user is in fact viewing a different site. Another demonstration showed how a tiny window containing IE’s padlock icon could be placed over the browser status bar to make it appear as if the user is accessing the site securely. Major threats also come from developers who have found ways to create windows that cannot be closed, or that appear offscreen so as to not be noticed. When combined with the disabling of the page’s context menu, vulnerability sniffing routines, and a pop-up ad generator, such a window can be exceedingly dangerous, not to mention unbelievably annoying. Variations include having a window attempt to imitate a user’s desktop and always stay raised, tiling the desktop with a quilt of banner ads covering all usable space, or the ever popular spawning window game that annoys unsuspecting users by creating more windows mysteriously from offscreen or hidden windows.


Team LiB
Previous Section Next Section


JavaScript Editor JavaScript Debugger     JavaScript Editor


©