OWASP Top 10 for Java EE

OWASP Top 10 2007

OWASP Top 10
for Java EE

The Ten most critical web application security vulnerabilities FOR JAVA ENTerprise Applications

OWASP Spring of CODE project 2007

This document is licensed under the Creative Commons Attribution-ShareAlike 2.5 license

Table of Contents

Introduction

Summary

Methodology

A1 – Cross Site Scripting (XSS)

A2 – Injection Flaws

A3 – Malicious File Execution

A4 – Insecure Direct Object Reference

A5 – Cross Site Request Forgery (CSRF)

A6 – Information Leakage and Improper Error Handling

A7 – Broken Authentication and Session Management

A8 – Insecure Cryptographic Storage

A9 – Insecure Communications

A10 – Failure to Restrict URL Access

Where To Go From Here

References

Introduction

Welcome to the OWASP Top 10 2007 for Java EE! This totally re-written edition lists the most serious web application vulnerabilities, discusses how to protect against them, and provides links to more information. This document uses the general OWASP Top 10 2007 as input, but the content is rewritten and adjusted to only discuss Java EE applications.

Aim

The primary aim of the OWASP Top 10 for Java EE is to educate Java developers, designers, architects and organizations about the consequences of the most common Java EE application security vulnerabilities. The Top 10 provides basic methods to protect against these vulnerabilities – a great start to your secure coding security program.

Security is not a one-time event. It is insufficient to secure your code just once. By 2008, this Top 10 for Java EE will have changed, and without changing a line of your application’s code, you may be vulnerable. Please review the advice in Where to go from here for more information.

A secure coding initiative must deal with all stages of a program’s lifecycle. Secure Java EEapplications are only possible when a secure SDLC is used. Secure programs are secure by design, during development, and by default. There are at least 300 issues that affect the overall security of a web application. These 300+ issues are detailed in the OWASP Guide, which is essential reading for anyone developing web applications today.

This document is first and foremost an education piece, not a standard. Please do not adopt this document as a policy or standard without talking to us first! If you need a secure coding policy or standard, OWASP has secure coding policies and standards projects in progress. Please consider joining or financially assisting with these efforts.

Another interesting project from OWASP is the OWASP Code Review project where you will learn how to review your Java EE applications for security vulnerabilities by examining the Java source code.

Acknowledgements

We thank MITRE for making Vulnerability Type Distribution in CVE data freely available for use. The OWASP Top Ten project is led and sponsored by Aspect Security.

Project Lead: Andrew van der Stock (Executive Director, OWASP Foundation)

Co-authors: Jeff Williams (Chair, OWASP Foundation), Dave Wichers (Conference Chair, OWASP Foundation)

The OWASP Top Ten for Java EE is created by Erwin Geirnaert (ZION SECURITY, OWASP Belux Board)
sponsored by the OWASP Spring of Code project.

We’d like to thank our reviewers:

Shreeraj Shah (Blueinfy Solutions) - Andrea Cogliati -
Jeff Williams (Aspect Security, OWASP Foundation) -
Yiannis Pavlosoglou (Information Risk Management PLC) -
John Wilander (OmegaPoint)

Summary

A1 – Cross Site Scripting (XSS) / XSS flaws occur whenever a Java EE application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim’s browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.
A2 – Injection Flaws / Injection flaws, particularly SQL injection, are common in Java EE applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker’s hostile data tricks the interpreter into executing unintended commands or changing data.
A3 – Malicious File Execution / Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect anyJava EE framework which accepts filenames or files from users.
A4 – Insecure Direct Object Reference / A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.
A5 – Cross Site Request Forgery (CSRF) / A CSRF attack forces a logged-on victim’s browser to send a pre-authenticated request to a vulnerable Java EE application, which then forces the victim’s browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
A6 – Information Leakage and Improper Error Handling / Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data or conduct more seriousattacks.
A7 – Broken Authentication and Session Management / Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users’ identities.
A8 – Insecure Cryptographic Storage / Java EE applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.
A9 – Insecure Communications / Java EE applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.
A10 – Failure to Restrict URL Access / Frequently, a Java EE application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

Table 1: Top 10 Web application vulnerabilities for 2007

Methodology

Our methodology for the Top 10 2007 was simple: take the MITRE Vulnerability Trends for 2006, and distill the Top 10 web application security issues. The ranked results are as follows:

Figure 2: MITRE data on Top 10 web application vulnerabilities for 2006

Although we tried to preserve a one to one mapping of MITRE raw vulnerability data to our section headings, we have deliberately changed some of the later categories to more closely map to root causes. If you are interested in the final 2006 raw data from MITRE, we have included an Excel worksheet on the OWASP Top 10 web site.

All of the protection recommendations provide solutions for the three most prevalent web application frameworks: Java EE, ASP.NET, and PHP. Other common web application frameworks, such as Ruby on Rails or Perl can easily adapt the recommendations to suit their specific needs.

Vulnerabilities, not attacks

The previous edition of the Top 10 ( contained a mixture of attacks, vulnerabilities and countermeasures. This time around, we have focused solely on vulnerabilities, although commonly used terminology sometimes combines vulnerabilities and attacks. If organizations use this document to secure their applications, and reduce the risks to their business, it will lead to a direct reduction in the likelihood of:

Phishing attacksthat can exploit any of these vulnerabilities, particularly XSS, and weak or non-existent authentication or authorization checks (A1, A4, A7, A10)
Privacy violations from poor validation, business rule and weak authorization checks (A2, A4, A6, A7, A10)
Identity theft through poor or non-existent cryptographic controls (A8 and A9), remote file include (A3) and authentication, business rule, and authorization checks (A4, A7, A10)
Systems compromise, data alteration, or data destruction attacks via Injections (A2) and remote file include (A3)
Financial loss through unauthorized transactions and CSRF attacks (A4, A5, A7, A10)
Reputation loss through exploitation of any of the above vulnerabilities (A1 … A10)

Once an organization moves away from focusing on reactive controls, and moves towards proactively reducing risks applicable to their business, they will improve compliance with regulatory regimes, reduce operational costs, and hopefully will have far more robust and secure systems as a result.

Biases

The methodology described above necessarily biases the Top 10 towards discoveries by the security researcher community. This pattern of discovery is similar to the methods of actual attack, particularly as it relates to entry-level ("script kiddy") attackers. Protecting your software against the Top 10 will provide a modicum of protection against the most common forms of attack, but far more importantly, help set a course for improving the security of your software.

Mapping

There have been changes to the headings, even where content maps closely to previous content. We no longer use the WAS XML naming scheme as it has not kept up to date with modern vulnerabilities, attacks, and countermeasures. The table below depicts how this edition maps to the Top 10 2004, and the raw MITRE ranking:

Table 1 OWASP Top 10 2004 vs 2007

OWASP Top 10 2007 / OWASP Top 10 2004 / MITRE 2006
Raw Ranking
A1. Cross Site Scripting (XSS) / A4. Cross Site Scripting (XSS) / 1
A2. Injection Flaws / A6. Injection Flaws / 2
A3. Malicious File Execution (NEW) / 3
A4. Insecure Direct Object Reference / A2. Broken Access Control (split in 2007 T10) / 5
A5. Cross Site Request Forgery (CSRF) (NEW) / 36
A6. Information Leakage and Improper Error Handling / A7. Improper Error Handling / 6
A7. Broken Authentication and Session Management / A3. Broken Authentication and Session Management / 14
A8. Insecure Cryptographic Storage / A8. Insecure Storage / 8
A9. Insecure Communications (NEW) / Discussed under A10. Insecure Configuration Management / 8
A10. Failure to Restrict URL Access / A2. Broken Access Control (split in 2007 T10) / 14
<removed in 2007> / A1. Unvalidated Input / 7
<removed in 2007> / A5. Buffer Overflows / 4, 8, and 10
<removed in 2007> / A9. Denial of Service / 17
<removed in 2007> / A10. Insecure Configuration Management / 29

A1 – Cross Site Scripting (XSS)

Cross site scripting, better known as XSS, is in fact a subset of HTML injection. XSS is the most prevalent and pernicious web application security issue. XSS flaws occur whenever aJava EE application takes data that originated from a user and sends it to a web browser without first validating or encoding that content.

XSS allows attackers to execute script in the victim’s browser, which can hijack user sessions, deface web sites, insert hostile content, conduct phishing attacks, and take over the user’s browser using scripting malware. The malicious script is usually JavaScript, but any scripting language supported by the victim’s browser is a potential target for this attack.

Environments Affected

All Java EE application frameworks are vulnerable to cross site scripting.

Struts has even had XSS problems in the built-in error pages, and application servers have problems with error pages, administrative consoles and examples.

VulnerabilitY

There are three known types of cross site scripting: reflected, stored, and DOM injection. Reflected XSS is the easiest to exploit – a page will reflect user supplied data directly back to the user shown in the following code snippet. The HTML page will return the search phrase unvalidated to the user:

out.writeln(“You searched for: “+request.getParameter(“query”);

Alternatively in a JSP:

<%=request.getParameter(“query”);%>

Stored XSS takes hostile data, stores it in a file, a database, or other back end system, and then at a later stage, displays the data to the user, unvalidated. This is extremely dangerous in systems such as CMS, blogs, or forums, where a large number of users will see input from other individuals. In this code snippet, data is retrieved from the database and returned in the HTML page without any validation:

out.writeln("<tr<td>" + guest.name + "<td>" + guest.comment);

With DOM based XSS attacks, the site’s JavaScript code and variables are manipulated rather than HTML elements. An easy example of a vulnerable HTML application can be found in the article referenced below from Amit Klein:

<HTML>

<TITLE>Welcome!</TITLE>Hi<SCRIPT>

var pos=document.URL.indexOf("name=")+5;

document.write(document.URL.substring(pos,document.URL.length));

</SCRIPT>

<BR>

Welcome to our system…

</HTML>

Alternatively, attacks can be a blend or hybrid of all three types. The danger with XSS is notwhich type of attack is exploitable, but that it is possible to inject a malicious payload. Non-standard or unexpected browser behaviors can introduce subtle attack vectors. XSS is also potentially reachable through any components that the browser uses, for example Watchfire discovered an XSS vulnerability in Google Desktop which is an integrated component in your browser.

Attacks are usually implemented in JavaScript, which, in its full capacity, is a powerful scripting language. Using JavaScript can allow attackers to manipulate any aspect of the rendered page. These include adding new elements (such as adding a login tile which forwards credentials to a hostile site), manipulating any aspect of the internal DOM tree, and deleting or changing the way the page looks and feels. JavaScript allows the use of XmlHttpRequest, which is typically used by sites using AJAX technologies ( even if the victim site does not use AJAX today.

Using XmlHttpRequest, it is sometimes possible to get around a browser’s same source origination policy - thus forwarding victim data to hostile sites. Fortify discovered a specific vulnerability with JavaScript and called this JavaScript Hijacking. This can allow for the creation of complex worms and malicious zombies that last as long as the browser stays open. AJAX attacks do not have to be visible and do not require user interaction to perform dangerous cross site request forgery (CSRF) attacks (see A5).

More information about Cross-site-scripting and technical details about exploiting XSS can be found in the book XSS Exploits.

Verifying Security

The goal is to verify that all the parameters in the application are validated and/or encoded before being included in HTML pages.

Automated approaches: Automated penetration testing tools are capable of detecting reflected XSS via parameter injection, but often fail to find persistent XSS, particularly if the output of the injected XSS vector is prevented via authorization checks (such as hostile user data, viewable only at a later time by administrators). Automated source code scanning tools can find weak or dangerous API calls but usually cannot determine the level of validation or encoding that has taken place. This typically results in a large number of false positives. Modern commercial static analysis tools are able to perform interprocedural data flow analysis and are configurable so that they can recognize validation methods and dramatically reduce the amount of false positives.No existing toolisable to find DOM based XSS, which means that Ajax based applications will usually be at risk if only automated testing takes place.

Manual approaches: If a centralized validation and encoding mechanism is used, the most efficient way to verify security is to check the code. If a distributed implementation is used, then the verification will be considerably more time-consuming. Testing is time-consuming because the attack surface of most applications is so large.

Protection

The best protection for XSS is a combination of "whitelist" validation of all incoming data and appropriate encoding of all output data. Validation allows the detection of attacks, and encoding prevents any successful script injection from running in the browser.

Preventing XSS across an entire application requires a consistent architectural approach:

Input validation. Use a standard input validation mechanism to validate all input data for length, type, syntax, and business rules before accepting the data to be displayed or stored. Use an "accept known good" validation strategy. Reject invalid input rather than attempting to sanitize potentially hostile data. Do not forget that error messages might also include invalid data
Strong output encoding. Ensure that all user-supplied data is appropriatelyentity encoded (either HTML or XML depending on the output mechanism) before rendering, taking the approach to encode all characters other than a very limited subset. Also, set the character encodings for each page you output, which will reduce exposure to some variants
Specify the output encoding (such as ISO 8859-1 or UTF 8). Do not allow the attacker to choose this for your users
Do notuse "blacklist" validation to detect XSS in input or to encode output. Searching for and replacing just a few characters ("<" ">" and other similar characters or phrases such as “script”) is weak and has been attacked successfully. Even an unchecked “<b>” tag is unsafe in some contexts. XSS has a surprising number of variants that make it easy to bypass blacklist validation
Watch out for canonicalization errors.Inputs must be decoded and canonicalized to the application’s current internal representation before being validated. Make sure that your application does not decode the same input twice. Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked

Java EEspecific recommendations:

Validation of input, server-side:
Use Struts validators to validate all input
Implement Java regular expressions to validate input using a positive security approach
Use JSF validation server-side:
f:validateLength for the allowed length of input
<f:validateLength minimum="2" maximum="10"/>
<h:inputText required=”true”> if an input field is required
Encoding of output:
Use Struts output mechanisms such as <bean:write … >, or use the default JSTL escapeXML="true" attribute in <c:out … >. Do NOT use <%= … %> unnested (that is, outside of a properly encoded output mechanism)
Use the OWASP Enterprise Security API classes Encoder and Validator

if ( !Validator.getInstance().isValidHTTPRequest(request) ) {

response.getWriter().write( "<P>Invalid HTTP Request - Invalid Characters</P>" );