RE: J2EE Application Security Code Review

[Jeff Robertson <jeff.robertson () digitalinsight com>]

Just some totally biased and largely unresearched opinions:

1) Good code is more securable. By "good", I mean modular, non-redundant.
Every component does one thing and does it well. Insert favorite software
development process motto here. If all their database access is going
through one class, and you find SQL injection, then they only have to fix
one class, not dozens (or hundreds).

2) On the subject of SQL, modern apps have less and less need or excuse for
using it. Not in the age of hibernate, JDO, etc. If they are using JDBC,
enforce 100% use of prepared statements for all queries that have changing
parameters.

3) Look for authorization to be enforced in the domain model layer. If they
want to enforce it either in the presentation layer or (more rarely) down in
the SQL layer, then fine it's "defense in depth". But authorization is
domain logic, and properly should be in the model.

4) If they don't have a "model" but rather a bunch of services (session
beans, web services, corba thingies, etc... any architecture that has a
bunch of stateless pseudo-objects that just "do stuff"), then that is where
the authorization should live.

5) Unless they're security experts, shoot them if they try to invent a
"better" HttpSession than the one that already exists in their web
container.

6) Assuming they aren't going to use container-managed, declarative
authentication (AFAIK its rarely used... I hope I'm wrong), then they really
need to be enforcing the requirement to authenticate at the level of the
entire web app by using a filter. Expecting individual servlets, jsps, etc.,
to check if the user is authenticated is just bad design (see #1).

7) They ought to be using some sort of framework (Struts, JSF, Tapestry,
Spring, anything!) in the web tier instead of just plain old JSP. Straight
JSP leads to spaghetti code too quickly, which makes it hard to review and
therefore increases the chances of a (security) bug.

8) They need to be using a framework, taglib, or other mechanism that makes
it so that the laziest, most default, most natural way to render information
to the screen is immune to XSS. "<%= somevariable %>" doesn't cut it. Cases
where the output actually needs to be raw HTML is what should require the
presentation-layer developer to write extra code, not the other way around.

9) Whatever logic (navigattion, authorization, etc) exists in the web tier
code, had better be in the "controller" part of it (ie., compiled Java
classes) rather than in the JSPs. The JSPs are too likely to be messed with
when someone wants to change the look-and-feel and end up losing important
logic.

10) All the basic web app stuff like "don't trust hidden fields", "don't
trust javascript validation", basically "don't trust" still applies to J2EE
as much as any other kind of app.

-----Original Message-----
From: Yousef Syed [mailto:yousef.syed () gmail com] 
Sent: Friday, October 28, 2005 6:03 AM
To: Web Application Security
Subject: J2EE Application Security Code Review


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