Stay ahead of Java security issues like SQL and LDAP injections

Common Java security issues

Java programmers should keep the following security challenges in mind when they are designing and writing Java applications.

SQL injections

SQL injections occur when an attacker inserts malicious SQL query code into a form. If the application fails to detect the malicious code and passes it onto a database, the database could be modified in a harmful way, or sensitive data could be exposed to unauthorized parties.

The proliferation of automated tools for SQL injections makes SQL injection attacks a widespread security challenge for Java applications and, for that matter, virtually any other type of application that might connect to a database today.

The solution to SQL injection attacks in Java is simple enough: Make sure your app properly validates input and prevents malicious code from being appended to data already accepted into a form. As a general rule and where possible, avoid dynamic queries to mitigate the risk of SQL injections in Java applications. Java's PreparedStatement class can also be helpful for preventing SQL attacks.

Java LDAP injections

Injection attacks that exploit Lightweight Directory Access Protocol (LDAP) statements represent another common attack on Java applications. Here, again, input validation is the key to preventing attacks.

In particular, Java developers can thwart most types of LDAP injection attacks if they escape LDAP special characters.

Other types of Java injection attacks

We've already covered SQL injections and LDAP injections, but injection attacks in Java applications don't end there. Connection string injections, cross-site scripting (XSS) injections and other types of attacks are all possible.

These types of attacks don't apply to all Java applications -- XSS is really only a serious risk with web applications, for example -- but they are another reminder of why input validation is so important.

SecurityManager vulnerabilities

SecurityManager is designed so you can run untrusted bytecode securely within Java applications. SecurityManager sandboxes the bytecode in order to prevent attacks.

If you can achieve the functionality you need without [SecurityManager], mitigate Java security risks, and avoid it.

This makes SecurityManager a great resource for Java security -- provided, of course, that it works correctly. The main risk of SecurityManager is the history of security vulnerabilities that's arisen within SecurityManager itself. These vulnerabilities sometimes allow isolated code to break out of the sandbox and execute attacks.

To an extent, managing SecurityManager and Java security issues is a problem not for developers but for system admins, who must keep Java runtimes up to date. However, developers can do their part and avoid sandboxes when possible. In other words, don't blindly trust SecurityManager. If you have to use it in an application, use it. But if you can achieve the functionality you need without it, mitigate Java security risks, and avoid it.

Malicious JARs

When a Java application loads JARs at runtime, sometimes, a hacker can trick the application into linking malicious JARs. This is an old security problem, and Java has introduced a number of checks over the years to help prevent it.

Some of these attack mitigation features act on their own accord, but developers can take full advantage of them by signing JARs. That way, signatures are verified at runtime and prevent intrusions. Programmers can also mitigate the threat posed by malicious JARS by restricting the access privileges of specific classes so that, if malicious code is loaded, natural security policies will limit the damage malicious code can do.