Back to article
Dig Your Own Hole: 12 Ways to Go Wrong With Java Security
January 6, 2010
Fortify, a company specializing in software security, offers a webcast that describes 12 common Java security pitfalls.
- Failure to Acknowledge Problem. Some Java application developers don't think they need to worry about security.
- 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.
- SQL Injection. Some applications perform queries based on unvalidated user input, allowing hackers to enter bad SQL (such as a DROP TABLE command).
- 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.
- Trust Boundary Error. Many applications make the mistake of storing untrusted datasuch as req.getParameter("name")in a trusted object, such as a session.
- Bad Credential Management. Common mistakes include hard-coding the database username and password, and storing them in clear text in a properties file.
- Bad Error Handling. Error messages and stack traces can provide hackers with useful information about your platform, API versions, and so on.
- 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.
- Configuring AJAX/Web Services. A configuration file may give clients access to too many methods. Remember that whitelisting is always safer than blacklisting.
- Buffer Overflow. When you use the Java Native Interface to call native code, you lose all the memory safety and type safety of Java.
- 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.
- Logging Sensitive Data. Log files may be harvested for email addresses, authentication data, and financial information.