OWASP exposure - XSS

DZone 's Guide to

OWASP exposure - XSS

· Java Zone ·
Free Resource
Second in a series covering the top 10 OWASP vulnerabilities from a Java programmer's perspective. This week - XSS.

What is OWASP?

Open Web Application Security Project is a non-profit organisation founded in the US to analyse, document and share information pertaining to the most common and severe vulnerabilities in today's web applications. Their goal is to educate us - should we fail to do it ourselves - on the security weaknesses that we emply unknowingly in our applications, how to identify them, and how to prevent them. Put simply, they're a bunch of nights in shining armor helping us write more secure web applications.

Their mission, as they state it, is:

 The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software. Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license.

Each year, OWASP publish a list of the web's top 10 vulnerablities that are found across the globe in an effort to educate and strengthen the applications made available to us all.

 It's our job as programmers to take heed of the advice and understand what we're doing wrong and to improve on it.

Top 10 – XSS

Cross-site scripting – or XSS – is a vulnerability that has widespread prevalence. According to the OWASP it's the most common security found on websites today, and this has earned it the number 2 spot on their list.

As defined by the OWASP, XSS is:

XSS flaws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content. There are three known types of XSS flaws: 1) Stored, 2) Reflected, and 3) DOM based XSS

The Lowdown

XSS attacks happen usually because some input – innocent or otherwise – is blindly trusted and handed about an application without concern. The golden rule or never trusting input is violated and an attacker can wreak havoc.

As OWASP defines it, there are three types of XSS vulnerabilities: stored, reflected and DOM.

Stored Attacks

I'd argue that these are the worst of the three because the attack is persistent. Let's say you have a page content form that takes amongst other items a page title. These are stored in the database directly without validation and upon successful storage the information is presented back to the user via a 'preview' page. In your JSP you do the following (assume pageBean is the model behind your form and represents values that were stored in your DB):


This simple, innocent scriplet lays the groundwork for a simple stored XSS. The user submits the form, the information is stored and you present it back to the user. What if a user entered “<script language='Javascript'>alert(“oh dear”);</script>” into one of those fields? When you present it back to the user the page would display a Javascript alert; harmless in this example for sure, but it only takes a more sinister perspective and you'd have scripts pulled in from all sorts of malicious sites – the user is helpless as the attack has all sorts of control under your organisation's banner. If this was part of a CMS that was accessible outside of your organisation a user could send out links to this post to any number of people and wreak havoc by collecting personal details (the user thinks “oh it's so-and-so's website, I can trust them!”) and so on.

To alleviate the issue above, you'd only have to use a JSTL c:out tag to output the page bean's title. By default the core out tag escapes XML so you don't have to worry.


Much the same as the stored attacks, reflected attacks can happen through poor input handling or by specially crafted URLs (which is again a form of poor input handling). When providing a search box for example, you'd rightly use a GET request for this. When showing the results you might summarise the input - “you searched for X” - and then present the results. If an attacker passed some Javascript in here and you didn't safely escape the input when summarising you'd have a vulnerability on your hands. All the attack then has to do is distribute an email or some other communication with a carefully crafted URL (that contains some Javascript that retrieves something elsewhere) and your users and their data are at risk.

DOM based XSS

Document Object Model – DOM – based attacks are slightly more complex then stored or reflected. These occur for example when client-side code is built using trusted values. If written incorrectly, the code acts or is structured upon certain expectations of input and that input is what can be leveraged to inject foreign code into the DOM. See the OWASP page on DOM XSS for a more comprehensive introduction.

Much of what you see from OWASP could be avoided by simple understanding of your input and by never trusting it! Don't blindly write input back to your users, and certainly don't store it without encoding it or sanitising it before use in dynamic code (and even then, sanitation code could be poorly implemented and give you a false sense of security.

I hope this has enlightened you or at least refreshed your memory on yet another critical aspect of development. Next week I'll cover authentication!


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}