Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

RE: Sample JAVA application

Subject: RE: Sample JAVA application
Date: Mon, 8 Nov 2004 08:51:44 +1100
Hi Tal,

        Of course, most of these issues are only appropriate when the
malicious code will be running on the same JVM as the "safe" code. I
think what the OP was asking for is specific problems with java *WEB*
applications; in the web scenario (an attacker external to the site)
then none of these issues apply ... (except maybe "storing secrets"
which isn't, obviously, java specific).

        Also most of your comments rely on a proper security manager
being in place around the evil code ... i.e. consider "make everything
final" ... You can undo and set final fields via reflection in java if
the security manager lets you. And all the other things (seriaizable,
etc) are totally context dependant ... 

-- Michael 

-----Original Message-----
From: Tal Mozes [mailto:TalM@comsec.co.il] 
Sent: Sunday, 7 November 2004 12:30 AM
To: Chris Vanden Berghe; webappsec@securityfocus.com
Subject: RE: Sample JAVA application

Hi Chris,

 

From my experience there are a lot of Java specific security issues to
check when doing a code review. I haven't seen a good paper on the
subject, but I'll try to give the start...

 

Issues to check:

 

*         Object Initialization

*         Reducing scope

*         Make Everything final

*         Don't Use Inner classes

*         Don't Depend on Package Protection

*         Avoid Code signing

*         Sign Only JAR Files

*         Make Classes Unclonable

*         Make Classes Unserializeable

*         Make Classes Undeserializeable

*         Don't Compare Classes by Name

*         Storing Secrets in Code 

 

Note that it is not a complete list, but a start.  I hope you'll get the
general idea by now...

Hope it helped,

Tal.

 

Tal Mozes

Application Security Consultant

www.comsec.co.il

 





**********************************************************************
This email message and accompanying data may contain information that is 
confidential and/or subject to legal privilege. If you are not the intended 
recipient, you are notified that any use, dissemination, distribution or 
copying of this message or data is prohibited. If you have received this email 
message in error, please notify us immediately and erase all copies of this 
message and attachments.

This email is for your convenience only, you should not rely on any information 
contained herein for contractual or legal purposes. You should only rely on 
information and/or instructions in writing and on company letterhead signed by 
authorised persons.
**********************************************************************


<Prev in Thread] Current Thread [Next in Thread>