The 10 Most Important Security Controls Missing in JavaEE

JavaEE has some excellent built-in security mechanisms, but they don’t come close to covering all the threats that your applications will face.  Many common attacks like Cross-Site Scripting (XSS), SQL Injection, Cross-Site Request Forgery (CSRF), and XML eXternal Entities (XXE) aren’t covered at all.

You can prevent your web applications and web services from being vulnerable to these attacks, but it’s going to take some work and testing.  Fortunately, the Open Web Application Security Project (OWASP) has issued the “Ten Most Critical Web Application Security Risks” report. 

Let’s take a look at how these important risks apply to JavaEE web applications and web services:

1. Injection - Injection happens any time a developers takes  untrusted information, such as request.getParameter(), request.getCookie(), or request.getHeader(), and uses it in a command interface.  For example, SQL injection happens if you concatenate untrusted data into a regular SQL query, like “SELECT * FROM users WHERE username=‘“ + request.getParameter(“user”) + “‘ AND password=‘“ + request.getParameter(“pass”) = “‘“;  Developers should use PreparedStatement to keep attackers from changing the meaning of queries and taking over database hosts.  There are many other types of injection such as Command Injection, LDAP Injection, and Expression Language (EL) Injection, and all of them are devastatingly dangerous, so be careful when sending data to these interpreters.

2. Broken Authentication and Session Management – JavaEE has support for authentication and session management, but there are many ways to go wrong here. You’ll have to make sure that all authenticated traffic goes over SSL, no exceptions.  If you ever expose a JSESSIONID it can be used to hijack a user’s session without their knowledge.  You should rotate the JSESSIONID when the user authenticates to prevent Session Fixation attacks.  And you should avoid the use of response.encodeURL() which adds the user’s JSESSIONID to the URL where it can be more easily disclosed or stolen.

3. Cross-Site Scripting (XSS) - XSS occurs when JavaEE developers take untrusted information from the HTTP request and put it in the HTTP response without proper contextual output encoding.  The attacker can use this behavior to inject their scripts into a website where they can hijack sessions and steal data.  To prevent these attacks, developers need to perform context-sensitive output encoding.  If you’re putting data into HTML, use &#xx; format. Be sure to quote your HTML attributes, as unquoted attributes can be terminated with many different characters.  If you’re putting untrusted data into Javascript, URLs, or CSS, use the appropriate escaping technique for each.  And be very careful when dealing with nested contexts, such as a URL in Javascript in an HTML attribute. You'll want an encoding library like OWASP ESAPI to help.

4. Insecure Direct Object References – Anytime your application exposes an internal identifier, such as a database key, a filename, or hashmap index, attackers may attempt to manipulate those identifiers to access unauthorized data.  For example, if you pass untrusted data from the HTTP request to the Java File constructor, the attacker may use "../" or null byte attacks to trick your validation. You should consider using indirect references to your data, to prevent this type of attack. The ESAPI library has support for ReferenceMaps that facilitate this indirection.

5. Security Misconfiguration – There are a lot of security settings in modern JavaEE applications and frameworks like Struts and Spring. Be sure you have reviewed them and set things up the way you want.  For example, beware the <http-method> tag in a <security-constraint>.  This indicates that the security-constraint only applies to the listed methods, allowing attackers to use other HTTP methods, like HEAD and PUT, to bypass the entire security constraint.  Most likely you should delete <http-method> tags from your web.xml.

6. Sensitive Data Exposure – Java has extensive cryptographic libraries, but they are not easy to use correctly. You should find a library that builds on top of JCE to provide easily and safely usable cryptographic methods. Some examples are Jasypt and ESAPI.  You should be using strong algorithms like AES for encryption and SHA256 for hashes.  Be careful with password hashes as they can be reversed using a Rainbow Table, so use adaptive algorithms like bcrypt or PBKDF2.

7. Missing Function Level Access Control – JavaEE supports both declarative and programmatic access control, but many applications still choose to create their own scheme. Frameworks like Spring also have annotation-based access control primitives. The most important thing is to be sure that every exposed endpoint has the appropriate access control check, including web services.  Don’t assume that your client can control anything, as attackers will access your endpoints directly.

8. Cross Site Request Forgery (CSRF) - Every state-changing endpoint needs to verify that requests are not forged. Developers should put a random token in each user’s session and then verify it when requests arrive. Otherwise, attackers can create "attack" pages by including malicious IMG, SCRIPT, FRAME, or FORM tags that link to the unprotected application. When the victim views such a page, their browser will generate a "forged" HTTP request to whatever URL is specified in the tag, and will automatically include the victim’s credentials.

9. Using Components with Known Vulnerabilities – Modern JavaEE applications have hundreds of libraries. Dependency resolution tools like Maven have caused this number to explode in the past five years.  Many widely used Java libraries have known vulnerabilities that can allow a web application using them to be completely subverted.  The solution is to stay on top of your libraries and keep them up to date. Don't just run a single scan, as new vulnerabilities are released every day.

10. Unvalidated Redirects and Forwards — Anytime your application uses untrusted data, such as a request.getParameter() or request.getCookie(), in a call to response.sendRedirect(), the attacker may be able to force a victim’s browser to an untrusted website designed to install malware.  A similar problem exists with forwards, except that the attacker may be able to forward himself to unauthorized functionality, such as administrative pages.  Be sure to carefully validate redirect and forward targets.

You should stay on top of these problems continuously. New attacks and vulnerabilities are identified all the time. Ideally, you'll integrate security checks into your existing build, test, and deployment process.

To check your applications for these problems, try the FREE Contrast for Eclipse plugin. It’s not a simple static analysis tool.  Instead, C4E takes advantage of the Java Instrumentation API to monitor everything in your application related to security.  C4E even does full data flow analysis in realtime, so it can trace data from the request through a complex application.  For example, imagine that your code takes a parameter value, base64 decode it, store it in a map, put the map in a data bean, store the bean in a session attribute, fetch the bean value in a JSP and insert it into the webpage using EL. Contrast for Eclipse will trace that data and report the XSS vulnerability.  Even if you are using complex frameworks and libraries.  No other tool comes close in terms of speed, accuracy, and ease of use.

You can find Contrast for Eclipse in the Eclipse Marketplace.  Then just go to the Servers tab and “Start with Contrast” — we’ll do the rest.