Category:OWASP Java Project

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.

Volunteer leader needed

The Java project is just getting started and we need a leader. The job requires a bit of project management skill and some editing skill, but doesn't require that you are the ultimate Java, J2EE, or security expert. There are plenty of those associated with OWASP. But we need someone to get us organized. If you're interested, please contact [email protected].

While Java and J2EE contain many security technologies, it is not easy to produce an application without security vulnerabilities. Most application security Vulnerabilities apply to Java applications just like other environments. The notable exception is buffer overflow and related issues that do not apply to Java applications.

Securing the Java Environment

Verifier and Sandbox JRE vs. JDK (precompile JSPs)

Securing Java Application Code

Common vulnerabilities like...Runtime.exec, Statement, readline() Dangers of native code, dynamic code, and reflection Tools like PMD and FindBugs Security mechanisms like cryptography, logging, encryption, error handling

Injection attacks

SQL injection attacks occur when an attacker includes raw SQL as input to a text field in an application. If the application uses that input to dynamically generate an SQL statement without first applying proper input validation and representation, the attacker's SQL may be executed as written in the database.

Most experienced Java programmers know to avoid this vulnerability through the use of Bind Variables in SQL Prepared Statements. But as Chess pointed out, injection attacks can also occur as "Filename Injection" writing to critical system files (often we might overlook ../../ included in a filename), "Command Injection," "XML Injection" or fundamentally in any string that may be interpreted by any part of the system at any time. In fact, it doesn't even have to be a String at all to be vulnerable to injection attacks. Therefore, input validation, which allows only inputs in a specified range of values, is a MUST for any system.

Cross-site scripting

Anytime a user can input data that at some later point will be returned to a browser, there is an opportunity for cross-site scripting. This occurs when a user includes malicious JavaScript in a data input field (such as "First Name" or "Address"). When the data is then later displayed to another user, the embedded JavaScript is interpreted and run by the unwitting user.

Bad credential management

This is keeping user names and passwords in code or files as PLAIN TEXT or using trivial Base64 encodings. (It's very common for JDBC connections.)

Bad error handling

Displaying exception stack traces in a browser window provides the attacker with the tools to "debug" your program.

Test code goes into production

Often programmers include hooks to support debugging in their applications. However, if the programmer fails to later remove ALL the logic, it can accidentally go into production, making it vulnerable to attack.

Native methods

All the security guarantees of Java are lost once Java calls Native code. Buffer overflows and the entire set of vulnerabilities commonly exposed in C and C++ programs are also possible in Java as a result of Native Method calls.

Concurrency/synchronization

Improperly written shared caches, or even simple member variables in servlets, can result in one user's data being displayed to another user. If this occurs once by accident, an attacker may latch onto the vulnerability until it exposes critical data, such as a credit card number.

Missing access control

Often programmers secure JSP pages by including security checks at the top of each page. Such a scheme is highly vulnerable because the security checks are sprinkled throughout the code rather than being contained in one central location. Even if access control is done in a filter, the vulnerability can still occur if the Web.XML fails to include the filter during deployment. The development process needs hooks to ensure that access checks are continually verified and audited.

Bad session management

Session hijacking occurs anytime an attacker can obtain data from another user's session. Best practices for protecting a session from being hijacked include the following: Issuing a new session ID when transitioning from an unauthenticated session to an authenticated session (or back). Truly invalidating the current session upon logout. If the session isn't invalidated, the attacker can "log in" again by simply clicking the back button. Ensuring sufficient randomness of session IDs to reduce the risk of an attacker "guessing" another user's session ID.

Cookies and other headers

Cookies and headers are just as vulnerable to "injection" attacks as text fields in forms. Often, programmers and frameworks remember to validate form input, but they overlook validation of headers and cookies. Cookies, headers, text fields and hidden form variables all represent data sent by the browser and cannot be trusted by the server without proper validation.

Logging sensitive data

The programmer's mantra of "log everything" can result in disaster if credit card numbers or other sensitive data accidentally make their way into log files.

Trusting the configuration

The configuration files from the local file system count as input data, too. These files should be checked for vulnerabilities and invalid input, otherwise an attacker can modify an input file and inject malicious behavior into an application.

Securing the J2EE Environment

Minimize attack surface in web.xml Configure error handlers

Securing J2EE Application Code

Vulnerabilities like... Using J2EE filters for protection Mechanisms like input validation, encoding Common vulnerabilities like...