Java has long boasted a reputation for being a secure programming language. Lately, however, that reputation has come into question. Java has been accused of being susceptible to cross-site scripting (XSS) and other similar input attacks like SQL injection.
Is the security of Java itself getting worse, or is the security of Web applications using Java weakening? Are XSS attacks enabled by poor Java coding, or poor Web application design? In this tip, we'll examine Java's security capabilities, the recent exploits that have caused some to question Java and best practices to keep Java applications safe.
Java security features
Java has a number of built-in security features that don't exist in other languages. For example, it checks the size of input data, which prevents buffer overflows, a common exploit where an attacker floods an application with more data than it can handle. A buffer overflow can crash an application or, if crafted properly, ignite a process which allows malicious access into a system.
Unlike other languages, such as C and assembly, Java automatically cleans up after itself. After an application closes, Java clears out memory used by the application with a garbage collection system. This process, which works silently in the background, prevents other exploits that can take down an application by overloading its memory.
 |
| For more information: |
Security expert Michael Cobb explains how application logic attacks occur and offers tactics for protecting your Web applications.
Information security threats pro Ed Skoudis reveals new tactics for protecting your system against cross-site scripting attacks.
In this expert Q&A, Michael Cobb examines how buffer overflows and memory leaks can cause serious harm to Web applications. |
|
|
|
|
Java's more robust enterprise version, J2EE, takes security a step further with a set of cryptography packages for encrypting data and safely storing encryption keys. J2EE also has configuration files that can further lock down a Java application by limiting access to authorized users and blocking access to unwanted ones.
Besides these features, Java has packages for authentication and code verification. The authentication packages allow login modules to be plugged in. Code verification checks Java bytecode as it's loaded into the application to make sure it's legitimate.
Common Java exploits
With all of Java's built-in security features, what could go wrong? Here are some of the most common exploits against Java and some of the best practices for avoiding them.
Recently, the most concerning exploits have been injection attacks, such as XSS and SQL injections, and session hijacking. (Java isn't as susceptible to buffer overflows since it checks the size of buffer inputs.)
Because Java is often used as middleware to connect front- and back-end systems, it's frequently used in Web applications to link Web sites and databases. This makes it susceptible to injection attacks, such as XSS and SQL injections, where attackers enter malicious code -- either on a Web site's forms, attached to the site's URL, or embed in a link on a seemingly innocuous Web page.
In XSS, the attacker uses the embedded malicious code to steal information from the Web site, such as login credentials or bank account information. SQL injection is similar, except the attacker inserts SQL instructions and tries to steal the same information from the back-end database providing data to the Web site.
Protecting against these kinds of attacks requires a combination of good coding practices, application design and project management. The best way to prevent injection attacks from a coding perspective is to do two things: validate and sanitize all input. Injection attacks are triggered by special characters, such as < and > in the case of XSS, and the humble apostrophe (') in SQL injection attacks. Developers can add code that checks input from Web sites for special characters (validation), and then removes them (sanitization). To further avoid SQL inject, developers should ensure malicious statements are avoided by coding strings that can't be concatenated into SQL statements and use prepared statements.
Another threat to Java is session hijacking, in which a malicious attacker impersonates a legitimate user by taking over their session. A hijacked session can be used to access the account of the real user to either get personal information or steal from his or her bank account.
The same rules apply in Java as in other languages for protecting sessions. These include creating a random and unique session ID and extinguishing it when the application is closed. The JSESSIONID output generated by Java can be coded to meet these criteria. Sessions can also be managed through cookies. Both cookies and session IDs can be compromised through XSS, so protecting against XSS is the best way to stop session hijacking using Java.
Summary
Java development projects should be managed for security, as would a project in any other language. Security requirements should be included in business requirements and functional specifications even before development starts. Security reviews should be incorporated into the project lifecycle with code reviews and testing at regular intervals. For Java in particular, Fortify Software Inc. offers a good tool for testing code for security vulnerabilities. Fortify also maintains the Java Open Review Project database of Java vulnerabilities. Another good source for information is the Open Web Application Security Project (OWASP).
Is Java any less secure now than it has ever been? Not really. It's taken some hits lately because it has been exposed to some of the same flaws plaguing other Web applications. But those flaws, like XSS, are part of the vulnerabilities associated with any coding for the Web, and aren't necessarily specific to Java. With a combination of safe coding practices -- like input validation and sanitization and secure session management -- as well as secure application design and building security reviews into the development lifecycle, Java projects can be made safe and secure.
About the author
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP, specializing in Web and application security, and is the author of The Little Black Book of Computer Security available from Amazon. He has a radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at http://www.theitsecurityguy.com.
