Cross Site Scripting – the Web’s lurking danger
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.
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:
- 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?
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?
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.
Posted in Security Insight