Skip to main content

The Top 10 Web Application security vulnerabilities starting with XSS

Posted by caroljmcdonald on September 29, 2009 at 9:09 PM PDT

This and the next series of blog entries will highlight the href="">Top
10 most critical web application security vulnerabilities
identified by the Open
Web Application Security Project (OWASP)

You can use OWASP's href="">WebGoat
to learn more about the OWASP Top Ten security vulnerabilties. WebGoat
is an example web application, which has lessons showing "what not to
do code", how to exploit the code, and corrected code for each


You can use the href="">OWASP
Enterprise Security API Toolkit to protect against the OWASP Top
Ten security vulnerabilties.


is a web application which demonstrates the many uses of
the Enterprise Security API.


OWASP Top 10 number 1: XSS = Cross Site Scripting

Cross Site Scripting (XSS) is one of the most common security problems
in today's web applications. According to the href="">SANS Top Cyber
Security Risks, 60% of the total attack attempts observed on the
Internet are against Web applications and SQL injection and Cross-Site
Scripting account for more than 80% of the vulnerabilities being
discovered. You are at risk of an XSS attack any time you put content
that could contain scripts from someone un-trusted into your web pages.

There are 3 types of cross site scripting:

  • Reflected XSS: is
    when an html page reflects user input data, e.g. from HTTP query
    parameters or a HTML form, back to the browser, without properly
    sanitizing the response. Below is an example of this in a servlet:

    out.writeln(“You searched for: “+request.getParameter(“query”);
  • Stored XSS: is when an
    Attacker’s input script is stored on the server (eg a database) and
    later displayed in the web server html pages, without proper HTML
    filtering. Examples of this are in blogs, or forums where users can
    input data that will be displayed to others. Below is an example of
    this in a servlet data is retrieved from the database and returned in
    the HTML page without any validation:

    out.writeln("<tr><td>" + + "<td>" + guest.comment);
  • DOM XSS: is when
    JavaScript uses input data or data from the server to write dynamic
    HTML (DOM) elements, again without HTML sanitizing/escaping/filtering.

XSS can be used to:

  • deface web pages
  • hijack user sessions
  • conduct phishing attacks
  • execute malicious code in the context of the user's session
  • spread malware

Protecting against XSS

To protect against XSS all the parameters in the application should be
validated and/or encoded before being output in HTML pages.

  • Always validate on the server side for data integrity and

    • Validate all input data to the application for type, format,
      length, range, and context before
      storing or displaying.
    • Use white-listing (what is allowed), reject if invalid,
      instead of filtering out black-list (what is not allowed).
  • Output encoding:
    • Explicitly set character encoding for all web pages
      (ISO-8859-1 or UTF 8):

      <%@ page
      contentType="text/html;charset=ISO-8859-1" language="java" %>
    • all user supplied data should be HTML or XML entity encoded
      before rendering.

Java specific Protecting against XSS

Validating Input with Java

  • You can use Java regular expressions to validate input, this
    example from WebGoat allows whitespace, a-zA-Z_0-9, and the characters
    - and ,


    String regex = "[\\s\\w-,]*";
    Pattern pattern = Pattern.compile(regex);
    validate(stringToValidate, pattern);

  • Use Framework (Struts, JSF, Spring...) validators. With Java EE 6
    you can use the Bean Validation Framework to centrally define
    validation constraints on model objects and with JSF 2.0 to extend
    model validation to the UI. For example here is a JSF 2.0 input field:

    <h:inputText id="creditCard" value="#{booking.creditCardNumber}"/>

    is the JSF 2.0 booking Managed Bean using the Bean Validation Framework

    public class Booking {
    @NotNull(message = "Credit card number is required")
    @Size(min = 16, max = 16,
    message = "Credit card number must 16 digits long")
    @Pattern(regexp = "^\\d*$",
    message = "Credit card number must be numeric")
    public String getCreditCardNumber() {
    return creditCardNumber;

    In addition there are new JSF 2.0 Validators:

    • href="">
      is a validator that delegates the validation of the local value to the
      Bean Validation API.
    • provides required field validation.
    • href="">
      provides regular expression-based validation

  • Use the href="">OWASP
    Enterprise Security API Java Toolkit's Validator interface:

    ESAPI.validator().getValidInput(String context,String input,String type,int maxLength,
    boolean allowNull,ValidationErrorList errorList)

    returns canonicalized and validated input as a String.
    Invalid input will generate a descriptive ValidationErrorList, and
    input that is clearly an attack will generate a descriptive

Output Encoding with Java

  • You can use Struts output mechanisms such as style="font-family: monospace;">, or use
    the default JSTL escapeXML="true"
    attribute in

  • JSF output
    components filter output and escape dangerous characters as XHTML


  • You can use the href="">OWASP
    Enterprise Security API Java Toolkit's style="font-family: monospace;">ESAPI Encoder.encodeForHTML()
    method to encode data for use in HTML content. The encodeForHTML()
    method uses a "whitelist" HTML entity encoding algorithm to ensure that
    encoded data can not be interpreted as script. This call should be used
    to wrap any user input being rendered in HTML element content. For



References and More Information:

  • href="">Bean
    Validation - The Java EE 6 Tutorial, Volume I
  • href="">JSF
    2.0 validation
  • XSSed
  • href="">Top
    10 most critical web application security vulnerabilities
  • Open Web
    Application Security Project (OWASP)
  • href="">OWASP
    Enterprise Security API

Related Topics >>