The last couple of years have seen a massive increase in the power and capabilities of browsers – or, at least, in the level to which the web development community takes advantage of them. New web applications such as Google Maps and the Zimbra collaboration suite have blurred the boundaries between a web page and a desktop application.

These sites take advantage of the browser's capability to issue script commands to make new web requests and obtain additional data without reloading the page you are on. So Google Maps downloads new tiles as you scroll around the map, and Zimbra downloads new e-mail messages and sends the ones you write back to the server, all without leaving the page. These scripting capabilities make a browser-based application look, feel and react much more like an installed program, and provide a better user experience.

However, it's rather important for web developers to make sure that the only scripts which run on their pages are the ones they've written. If an attacker can find a way to inject their own scripts, they can use that power to make changes to the site which the developer or user may not want.

Programming mistakes which allow this to happen are called Cross-Site Scripting, or XSS flaws. They most often occur when a site reprints user input – say the search words for a search - without carefully filtering it to remove programming commands.

The browser's ability to do things in the background also means that a malicious site you visit (perhaps inadvertently) can, without your knowledge, start attempting to exploit XSS holes in other websites. If it finds a flawed site where you are already logged in, it can then start to manipulate the site and make changes to it in your name. This is called "session riding" - the attacker is using the log-in credentials you previously established with the site to pretend to be you.

If that flawed site happens to be your bank, then you are in trouble. The attacker could take any action you could, including transferring money into an account he controls.

To their credit, most banks are aware of this issue and have checked their sites carefully for this sort of programming mistake. But script injection holes have been found recently in the websites of large blogging communities like Livejournal and Xanga. In both cases, it was used to write a fairly simple replicating "worm" which posted the equivalent of "I'm the king of the castle, you're a dirty rascal", along with code to continue the propagation, to the weblogs of anyone who visited an infected page. But it could have been a lot worse.

There already exist complete XSS remote control toolkits. As soon as the attacker has the ability to run scripts in your browser – either because you've visited a page he controls, or because he's exploited another XSS hole to inject his script into an innocent site you visit often – he can set up a system where your browser is contacting sites all over the web to see if you are logged into them and, if you are, uses your credentials to make any sort of change the attacker desires.

There's not much individual users can do to protect themselves, except for disabling scripting entirely, which would break a large number of sites and deprive them of the great benefits of the new generation of web applications. Neither the web developer community nor the cracker community have yet woken up to the dangers (or opportunities) of XSS. Whether this problem turns into a catastrophe depends on who does so first.

Gervase Markham works for the Mozilla Foundation, a non-profit organisation dedicated to promoting choice and innovation on the internet. His blog is Hacking For Christ.

Times Recommends

• Lies and cover-up at MG Rover exposed by report
• High oil prices push manufacturing costs up
• Primark founder steps down as chief executive