J2EE Application Security

Digital Certificate based SSL for network security and Authentication/Authorization based on the security-constraints tag in deployment descriptors for Access Control is quite standard for J2EE Application.However that is not the end of protecting your J2EE Application.If yours is a Web Application, there are a number of application vulnerabilities which a attacker can make use of and get into your application. Please refer to OWASP Top Ten (http://www.owasp.org/index.php/OWASP_Top_Ten_Project)for list of most important Web Application vulnerabilities.Following are 3 most important (according to me) vulnerabilities for J2EE Web Application.
1) Cross Site Scripting (XSS) - Assume you a Web page where user can enter some text data and another page where these use entered data is displayed (Some thing like 'add comment' and 'moderate comments' pages). An attacker may enter a script instead of text data in the input text area (eg: '[script]echo 'this is a sample attack'[/script]). When the somebody else (say administrator) opens the second page instead of the text being displayed the script shall be executed. This is called XSS.The solution for this kind of attach is:a) Validate all user inputs - in this case we should not allow patterns like [script]b) Encode all output content (not formatting metadata). If output is encoded even if [script] is present in the text, that will be displayed as [script] instead of executing.For practical purpose you need to validate input as well as encode output content.
2) SQL Injection - Assume you have a authentication servlet. You store the username password in database use the following SQL for authentication. "select 1 from user_table where username = '" + username + "' and password = '" + password + "'"; An attacker may enter the following text as username and passwords
Username = "abc' OR 1 = 1; --
Password = xyz
NOw the SQL becomes "select 1 from user_table where username = 'abc' OR 1 = 1; -- password = 'zyz'; which is all ways trueSolution for this kind of attack is Using PreparedStatement instead of Statement.
3) Cross Site Request Forgery (CSRF) - Assume you are using FireFox and in one tab you have opened your web application. Now get a email (from attacker) with some links to some fancy pictures. Actually the link is to your application with query string indicating to do some operation. Since you are already logged in to the application it will not ask for authentication again. It will silently execute the operation. Solution for this kind of attack is to use a unique string (other than session id) to identify each session/request (It identifier could be per session or per request; per session is sufficient for most purposes). You need to attach this identifier to each form and link in your application. Validate all request for a valid identifier.
Vulnerabilities in Swing clients
1) SQL injection is equally valid in Thick clients. Solution is same - using Prepared statements
2) Un protected JNDI objects - There is no standard way for protecting JNDI objects in J2EE. If an attacker can get hold of a DataSource or JMS Queue or topic he could access the application. or invoke SQL queries directly. Solution is to protect all JNDI resources in App server vendor specific way
3) Unprotected EJBs - Some times In swing client you first log in and then navigate other screens to do operations hence even if the subsequent EJBs are not protected you may not notice it. However a attacker can write own EJB client which can directly invoke the un protected EJB Solution is to protect all the EJBs