What is cross-site [xss] scripting?

There are some areas of computer security over which a user has very little control (software vulnerability exploits, hijacked DNS servers, drive by downloads, etc) and not much that a user 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 (Adobe) and by responsible authorities to deploy an Internet infrastructure that's less vulnerable to abuse. 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.

Cross-site scripting (XSS)
Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which enable malicious attackers to inject client-side script into web pages viewed by other users. 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. 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, which they do this by forcing the user's browser to run the scripts placed on those vulnerable web servers. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites were roughly 80% of all documented security vulnerabilities. Their impact may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site, and the nature of any security mitigations implemented by site owner.

In order for XSS attacks to succeed, certain criteria must be met.
1] The use of flawed browser software that does not validate the script's origins and permissions
2] 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.

Different types of XSS
There are currently three types of cross-site scripting vulnerabilities
  • Local (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 or IM). 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 (Type 1) 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 (Type 2) 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.

Why do they do it?
Most attacks target session cookies. 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. 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, they 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 then 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 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. 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. A very good 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 is also very important to keep your browser and Windows up to date so that any past vulnerabilities won't apply and leave you vulnerable.

Vanish.Org Copyright © 2006 All rights reserved