1 2 3 next »

Cross-Site Scripting: Data theft on the rebound

Daniel Bachfeld

Attacks on web clients with cross-site scripting and cross-frame scripting

One seemingly harmless click on a hyperlink - and cookies, passwords and form contents can be transmitted to an attacker. Even if the link points to trustworthy pages, you cannot be safe from data theft. Cross-site scripting and cross-frame scripting are the names of these attack techniques, and they are becoming increasingly widespread. This article explains how they work and how to protect yourself against them.

Four things play the main roles in the drama called cross-site scripting (XSS): an attacker with a manipulated hyperlink, a web application which delivers dynamic pages, a web client with JavaScript enabled, and a cookie containing user data. Centre stage is held by the web application, which generates pages from user input that are sent to it:

http://www.trusted.page/cgi-bin
  /test.cgi?something

It is not unusual to transmit variables in a URL; HTTP supports this with the GET method. On the server side, a script is being started which reads the variable, generates a new page, and then sends this to the web browser. The example above, for instance, is from the Apache standard installation. The script test.cgi returns the environment variables that it has stored in a so-called hash:

print "%ENV:\n", map { "$_ = $ENV{$_}\n" } keys %ENV;

In addition, it displays the so-called query string after the question mark (here: "something"), and this means that user input gets sent back to the browser. If this is done completely unfiltered, as it is in this case, a small JavaScript can be transmitted to the server as a URL argument. The server makes it an HTML document and then sends it back. The echo can have disastrous effects when the code is executed in the browser.

For the Apache test script, nobody will blame the programmer for making a mistake. In web shops, web mailers and portals, this is a different matter; the arguments should be filtered carefully.

The script below opens a small window with the text "Surprise" and an OK button for closing it:

http://www.trusted.page/cgi-bin
  /test.cgi?<script>alert("Surprise")</script>

Of course, the script could also have been embedded in an HTML document on the server, so where's the problem? For security reasons, JavaScript is only admitted for user-defined, trustworthy web servers, or IE prompts explicitly if you want to execute each script. Only when JavaScript is received from one of the trusted servers does it get executed by the browser. The browser's decision is based on the URL that is sent along.

1 2 3 next »