Internet Security Tips and Advice

Cross Site Scripting – the Web’s lurking danger

July 23rd, 2008 by Igor Pankov


There are some areas of computer security over which a user has almost no control; from involuntary exposure to software vulnerability exploits to hijacked DNS servers that divert visitors to infective locations, there is little that a user alone can do to avoid becoming a victim.

These challenges – as well as a multitude of others – require action by software vendors to design less vulnerable products and by responsible authorities to deploy an Internet infrastructure that’s less vulnerable to abuse – or at least enable fast mitigation when flaws are found.

The same principle can be applied to cross site scripting attacks. This type of web compromise cannot be solved by individual Web users alone but should be the responsibility of web application and browser developers. However, it appears this level of prevention won’t be available for some time, so it’s important to recognize the impact of cross site scripting vulnerabilities and minimize inadvertent exposure wherever possible. That’s the topic of this article.

What is cross-site scripting?

A script is a set of machine language commands processed on a user’s computer or by a web server. Cross-site scripting (XSS) vulnerabilities occur when scripts originating on one website (usually a malicious site) are permitted to interact with the content of another website, or an HTML page stored locally – hence the term “cross-site”. Unlike other types of attack, the perpetrators of cross-site scripting attacks use vulnerable servers as an intermediary to stage attacks on visitors to compromised websites; they do this by forcing the user’s browser to run the scripts placed on those vulnerable web servers.

XSS vulnerabilities first appeared at the turn of the century, when a number of security experts reported concerns over the potential use of JavaScript code with malicious intent in a cross-boundary attack.

In an XSS attack, after the script has been executed on the user’s PC, it starts issuing commands and remotely controlling the behavior of the target browser window in such a way that it appears the user is performing these actions himself. The script may execute locally on the user’s computer or lie dormant on the web server, attacking other users as they access this page.

The problem with XSS is so significant because, as a result of an XSS exploit, the script takes control of the victim’s web session while the attack is carried out in the background, leaving no footprint behind and thus making it extremely hard to detect.

In order for XSS attacks to succeed, certain criteria must be met: the use of flawed browser software that does not validate the script’s origins and permissions, or poorly-written Web server code that does not exercise proper validation routines. Social engineering is also widely used to lure victims into clicking the link containing the malicious script.

To give an idea of the scale of the problem, it is estimated that more than half of all websites today have XSS holes, and XSS flaws account for more than 80 percent of all documented web vulnerabilities. Almost every well-known web portal has been compromised by XSS attacks at some time – the likes of Google, MSN, Facebook and other prominent sites have experienced XSS exploits first-hand.

Different types of XSS

There are currently three types of cross-site scripting vulnerabilities:

  • Local, or Type 0, XSS, where the problem exists in the client-side script of a web page. To exploit the vulnerability, an attacker constructs a web page with malicious JavaScript code in it and sends potential victims a link to it (via email, IM, etc.). Once the link has been clicked, the script executes and serves up a locally-created vulnerable HTML page which contains JavaScript code that can be run with the the current user’s privileges (most users log on as Administrators). After that, an attacker can gain access to the victim’s local computer, including viewing files and other sensitive data.
  • Non-persistent, or Type1, XSS is one of the most common, and involves vulnerabilities of server-side scripts that do not sufficiently validate user input. Non-persistent XSS occurs when a user receives a link with malicious script while logged on to a web site. After the link is clicked and the malicious script executed, it hijacks the user’s session and controls the activity of the page the user is currently on. This type of compromise can be executed in the current browser session only.
  • Persistent, or Type2, XSS is the most blatant and dangerous vulnerability because it can affect many users without the use of much social engineering. The vulnerability is in the server-side scripts but can exist for a long time, so it can affect a much greater number of users. It arises when a legitimate server persistently stores portions of malicious scripts placed on it by the hacker and later feeds that code to the visitors’ browsers for the latter to execute.

What the perpetrators are after

Most attacks target session cookies – files loaded onto users’ machines by the web sites they connect to. Cookies are easy mechanisms for identification on the site, so once the perpetrators get hold of your cookie files, they can impersonate you and act on your behalf. Cookies are transferred to attackers by the commands in the script.

What victims can lose

As a result of successful exploitation of an XSS hole, victims may lose important data and be exposed to ID theft. Once your session has been hijacked, the “script masters” can perform any activity that a legitimate owner of the compromised account can do – read and delete emails, perform financial transactions and credit payments, create postings on social networking sites – just about anything the legitimate user is authorized to do.

What makes XSS attacks possible?

XSS attacks happen for two reasons: sloppy programming and haphazardly-created website engines that do not filter user input. Either of these situations can enable a malicious user to insert a piece of a JavaScript code in, for instance, a search field; the server would return a results page along with the original search query, which could be interpreted by the client software as executable code. So it’s important that web developers create code that filters user input and translates certain characters used in JavaScript into plain text, not executable commands.

Another contributing factor to XSS vulnerability is the use of outdated web browsers that don’t apply the necessary security policies when processing (parsing) code coming from different sources.

How can users protect themselves?

While developers carry much of the blame for the majority of XSS attacks, there is still something a web user can do to minimize vulnerability. The key element is preventing client-side code from being sent to the browser by untrusted websites. Internet Explorer users can do this by raising their security slider to “High” in the Security tab, restricting the ability of any potentially malicious code on any website to run, and specifying a list of sites that are still allowed to run code. Firefox users can use the NoScript addon to block JavaScript and only allow it on sites specified in the exclusion list, as it is the case for IE. Another option would be to increase the Privacy setting in IE so that no permanent cookies are stored by the browser, and to specify a set of exclusions.

Another useful habit to get into is to always log off from a web session when it’s completed, and to open unknown links only after the user has left the site (the cookie file is removed from local storage and no attack is possible).

It’s also important to keep your browser and Windows up to-date so that any past vulnerabilities won’t apply to leave you vulnerable.


XSS attacks arise because of errors in web code that does not sufficiently check user input for malicious executable code. Vulnerability is avoided if potentially-malicious data that a user submits to a server is extracted and returned as plain text (non-executable) data. While we wait for a solution from web application developers, there are actions users can take to minimize their exposure to XSS: logging off from a session before clicking and following any links, disabling JavaScript code for unknown sites, using the latest versions of web browsers. And lastly, continue to follow the ‘rules of the web’ – don’t open links from strangers and don’t trust contacts you don’t know.

Posted in Security Insight

2 Responses

  1. Manny Carvalho

    Nicely written article Igor. I usually learn something from them. Thank you.

  2. bart ragusa

    excellent article-you have a marvelous capacity for describing the problem in terms that can be understood by any reasonably alert, but not technically trained person especially if we are concerned with the multiple ways the positive potential of the web can be undermined by malicious actions. Thank you