File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Security and the fly likes Enterprise Application Security Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Enterprise Application Security" Watch "Enterprise Application Security" New topic
Author

Enterprise Application Security

Krishna Mohan
Ranch Hand

Joined: May 30, 2003
Posts: 44
"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?
Vijay S. Rathore
Ranch Hand

Joined: Oct 29, 2001
Posts: 449
"Enterprise Application security " Consist of the following attributes followed by the J2EE implementations.
Authentication
Digital Signatures, Certificates
Authorization
Security Manager, Java Protected Domains
Confidentiality
Encryption, SKIP Technology
Containment
Class Loader, Sandbox, Java Protected Domains, Byte Code verifierer
Auditing
Limited, Security Manager, Future enhancements pending
Non-repudiation
Digital Signatures, Message Digest

Regarding common practises and mistakes I think it's an ongoing process like the Virus/Antivirus paradigm.


SCJP, SCJD, SCWCD1.4, IBM486, IBM484, IBM 483, IBM 287, IBM141, IBM Certified Enterprise Developer - WebSphere Studio, V5.0
Author of IBM 287 Simulator Exam
Pankaj Kr
Author
Ranch Hand

Joined: Sep 09, 2003
Posts: 80
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.


Pankaj Kumar
Home - WebLog - J2EE Security
Juan Rolando Prieur-Reza
Ranch Hand

Joined: Jun 20, 2003
Posts: 236
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
Krishna Mohan
Ranch Hand

Joined: May 30, 2003
Posts: 44
Thanks Pankaj.
Pankaj Kr
Author
Ranch Hand

Joined: Sep 09, 2003
Posts: 80
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.
 
wood burning stoves
 
subject: Enterprise Application Security