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

You can use OWASP's 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 vulnerability.




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



The ESAPI Swingset 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 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>" + guest.name + "<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 security:
  • 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}"/>

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

  @ManagedBean 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:
  
  • <f:validateBean> is a validator that delegates the validation of the local value to the Bean Validation API.
  • <f:validateRequired> provides required field validation.
  • <f:validateRegexp> provides regular expression-based validation
    
  
  
  
• Use the OWASP Enterprise Security API Java Toolkit's Validator interface:
  

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

  ESAPI.validator().getValidInput() 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 IntrusionException.
  

Output Encoding with Java

• You can use Struts output mechanisms such as <bean:write… >, or use the default JSTL escapeXML="true" attribute in <c:out … >
  
  
• JSF output components filter output and escape dangerous characters as XHTML entities.
  
  <h:outputText value="#{param.name}"/>
  
  
• You can use the OWASP Enterprise Security API Java Toolkit's 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 example:

  <p>Hello, <%=ESAPI.encoder().encodeForHTML(name)%></p>

References and More Information:

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