This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
"Enterprise Application security ". How is this taken care in the real world J2EE projects (in production )as of today ? What are some of the common practises / mistakes ?Which areas need improvement? Could someone throw some light on this?
Some practical tips (for high security prodcution environments): 1. Don't store passwords in text-files. (This is more common than believed). 2. Protect resources (web pages, EJBs, EJB methods, ...) using appropriate descriptor files. 3. Don't use RMI based applications (because anyone who can access the machine can invoke the methods). 4. Avoid HTTP-Basic over plain HTTP (HTTP-Basic over HTTPS is fine). 5. Dono't irritate the legitimate user (by asking for passwords too many times). 6. Validate all user input that goes to other programs (database, shell commands). 7. Do not return back user entered data to user's browser in a Web App. (to avoid Cross Site Scripting attacks ). 8. Fail gracefully (ex: if the certificate validation fails, don't just abort or continue silently -- let the user know the reason for failure and ask if he/she wishes to continue). 9. If you are developer then think of how a deployer might change security policies at deployment time. I could go on. But this brief list should give a good idea of what is needed.
Originally posted by Pankaj Kr: ... 3. Don't use RMI based applications (because anyone who can access the machine can invoke the methods)...
Pankaj, What a useful list of guidelines. I have a humble question about #3. Wouldn't it be reasonable to enforce RMI over SSL by, for example, tunneling through HTTPS ? This should work and eliminate the security hole you pointed out. Thanks once again!
Juan Rolando Prieur-Reza, M.S., LSSBB, SCEA, SCBCD, SCWCD, SCJP/1.6, IBM OOAD, SCSA
Joined: May 30, 2003
Joined: Sep 09, 2003
Originally posted by john prieur:
I have a humble question about #3. Wouldn't it be reasonable to enforce RMI over SSL by, for example, tunneling through HTTPS ? This should work and eliminate the security hole you pointed out. Thanks once again!
Yes, RMI over SSL does eliminate a certain category of security risks. The data gets encrypted so it cannot be read or modified (without detection) in-transit. However, it doesn't solve the problem of authentication the client program (unless you use a cert-based client authentication, which has problems of its own) and authorization at the method level. Tunneling through HTTPS (or just HTTP) has many more limitations. In fact, SSH based tunnel may be more appropriate. See my articles on this in JavaRanch Newsletter: part1 and part2.