One of the most common forms of Web application vulnerability is Cross-site Scripting. This security vulnerability allows attackers to implant malicious scripts into websites. The scripts will execute in the browsers of visitors to the site, within the hosting website security zone. This provides the script with the correct privilege level to access and modify secure data.
Cross-site Scripting is among the most widespread attack methods used by hackers. It is also referred to by the names XSS and CSS. Note that in this case, CSS is not the same as Cascading Style Sheets, which is the name of a style sheet language for Web pages.
Possible consequences of Cross-site Scripting include having a user account hijacked (also called cookie theft), the redirection of users to a fraudulent website, or the display of false information on the hosting website. In addition to the threat of secure data being compromised, the trust level of users can be seriously damaged by Cross-site Scripting.
How Does an XSS Attack Occur?
Most modern Web applications are dynamic in nature, allowing users to customize an application website through preference settings. Dynamic web content is then generated by a server that relies on user settings. These settings often consist of personal data that needs to be secure. Unfortunately, dynamic websites are most vulnerable to XSS attacks on secure data.
Web pages that pass data to and from a database are especially vulnerable to XSS attacks. This includes pages with login ids and passwords, shopping carts that access credit card data, personal information forms, etc. Retail, health care, government and financial Web applications are especially at risk.
Malicious HTML, JavaScript, VBScript, Flash or ActiveX scripting code can be used for XSS. Once inserted into an unsecured dynamic website, the embedded script is able to gather private data, create user requests to the Web application, steal user cookies or launch a virus on the user’s computer. The script could also cause the user to redistribute malicious content across the internet.
Once a hacker is armed with sufficient knowledge to write malicious code in a dynamic language such as JavaScript or HTML, the code can be easily tested through a browser on a dynamic website
According to CERT Coordination Center, a federally funded research and development center, the lack of control over user inputs puts dynamic websites at risk. Unless proactive steps are taken to guard against malicious input, a Web application cannot guarantee the security of its output.
Don’t Ignore the Threat of Cross-Site Scripting
Industry data shows that XSS is a widespread and serious form of attack on Web applications. Anytime a website requests a user to type in information, the risk of XSS exists. Many of the Web applications that we work with are vulnerable to the threat of XSS. Industry research suggests that this is a growing trend with no end in sight.
Example of XSS Attack
Consider a search engine website that is not secured against Cross-site Scripting. The user interface of the search website consists of an input field. After the user types in a search term and hits enter, an output web page displays a list of items that match the search term.
These are the steps involved in the XSS attack:
1. Hacker types in a harmless search term like “This is an XSS attack”
2. The search engine generates this URL, which contains the embedded search term:
http://google.com/search.php?q=XSS%20attack
3. This gives the hacker the name of the php script used by the search engine (search.php in this case).
4. Now the hacker enters this type of search term:
<script type=”text/javascript”> alert(‘This is an XSS attack’) </script>
5. This search term is submitted to search.php and this URL is created:
http://google.com/search.php?q=%3Cscript%3Ealert%28%91This%20is%20an%20XSS%20attack%92%29%3C%2Fscript%3E
When the search engine displays the output page, if it is vulnerable to attack the message saying “This is an XSS attack” will be shown rather than a list of matching search items. The hacker now knows that it’s possible to launch a full-blown XSS attack on the search engine. This is a simple example, but it illustrates how a more dangerous script could be used to attack the search engine.
Protecting Against Cross-site Scripting
The first line of defense against Cross-site Scripting attacks is verification and filtering of Web application input strings (in both ASCII and Hex form). This means identifying every point in a website’s scripts where user input is requested.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
