Dig Your Own Hole: 12 Ways to Go Wrong With Java Security

Fortify, a company specializing in software security, offers a webcast that describes 12 common Java security pitfalls.

1. Failure to Acknowledge Problem. Some Java application developers don't think they need to worry about security.
2. Denial of Service. With Java, you don't always know how much data is being stored in a variable such as a String, so it's possible to run out of resources.
3. SQL Injection. Some applications perform queries based on unvalidated user input, allowing hackers to enter bad SQL (such as a DROP TABLE command).
4. Cross-Site Scripting. This can happen when user input is not validated before it is output. An attacker may inject code that gets sent to a victim's browser.
5. Trust Boundary Error. Many applications make the mistake of storing untrusted data—such as req.getParameter("name")—in a trusted object, such as a session.
6. Bad Credential Management. Common mistakes include hard-coding the database username and password, and storing them in clear text in a properties file.
7. Bad Error Handling. Error messages and stack traces can provide hackers with useful information about your platform, API versions, and so on.
8. Bad Exception Handling. An example would be defaulting to an insecure method (such as using java.util.Random to generate a session ID) when the more secure method fails.
9. Configuring AJAX/Web Services. A configuration file may give clients access to too many methods. Remember that whitelisting is always safer than blacklisting.
10. Buffer Overflow. When you use the Java Native Interface to call native code, you lose all the memory safety and type safety of Java.
11. Race Conditions. Examples include creating a File object and trying to access its properties before it's ready, and using public member fields in a servlet to store user-specific data.
12. Logging Sensitive Data. Log files may be harvested for email addresses, authentication data, and financial information.