Yousef,
The best bet is to read the OWASP Guide 2.0 (http://www.owasp.org)
and look at Howard and Le Blanc's excellent Writing Secure Code. WSC
contains the Microsoft Threat Modeling process, which is the best way
to concentrate on those issues which could cause actual loss. You can
also find this info on the Microsoft Patterns and Practices (PAG)
website:
http://msdn.microsoft.com/practices/default.aspx?pull=/library/en-us/
dnpag2/html/tmwa.asp
Once you have detailed the threats, you should use the OWASP Guide to
help you find if the code sticks to best practices and have a look if
it is sub-standard in any.
In J2EE, the primary things to look for are:
a) the use of Struts. I like it because by default <bean:write> and
friends are nearly XSS proof
Struts also has validation.xml - apps should be using this. If not,
start using it. It's a freebie that makes parameter tampering that
much harder (still allows * injection though for strings)
b) JSPs should in WEB-INF - prevents source code inclusion and direct
access
c) Make sure that if JAAS is in use, that the actions (foo.do etc)
are access controlled via JAAS rather than just allowing all. If JAAS
is not in use, find out why and see if you can fix that.
d) In your container's security manager configuration, look at the
permissions the Java code is running under. It should be minimalist -
unfortunately, it's normally AllPermission (slackers!)
Start with nothing and watch for stack traces for permission errors.
Allow those only after you have assured yourself that the code is
properly protecting itself (for example, if it wants file access,
make sure you've dealt with file ACLs, file system traversal, etc)
before allowing access to the local file system.
e) Find any use of Runtime - access to the local environment is
usually fairly woeful.
Other than that, the things in OWASP Guide should give you plenty to
get on with - I'll give a secret away - I wrote or revised most of
the controls in the Guide at night whilst doing J2EE code reviews
during the day, so many controls are already slanted to J2EE :)
I'm sure many others will chip in on J2EE code reviews.
thanks,
Andrew
On 28/10/2005, at 8:02 PM, Yousef Syed wrote:
Hi,
I've been tasked with performing a Code Review on for Security on a
J2EE Application's code.
Though I've taken part in numerous Code Reviews, I've never done one
searching for Security issues.
Can someone please advise me on what I should be looking for?
Where can I get further information on the procedure that should be
followed?
Are there any Standards/Best Practices for Securing J2EE applications?
Thanx,
ys
--
Yousef Syed
