Category:OWASP Java Project

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 owasp@owasp.org.
 * Volunteer leader needed

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...