Re: J2EE Application Security Code Review

["Dean H. Saxe" <dean () fullfrontalnerdity com>]

Jeff,

As usual, I agree with you 100%!  But, there is one more thing to add:

Whenever I see a development group devise their own framework for web  
applications I get worried.  (I'm not talking about the one we did  
for CF5, since nothing better existed at the time!)  I cannot tell  
you how many Java apps I reviewed in the last few months that have  
implemented some half-baked (there was another, less kind word in  
there in the first draft!) version of Struts or other MVC-like  
frameworks.  YUCK!  That always raises a red flag.

-dhs

Dean H. Saxe, CEH
dean () fullfrontalnerdity com
"Great spirits have often encountered violent opposition from weak  
minds."
    --Einstein


On Oct 28, 2005, at 7:57 AM, Jeff Robertson wrote:

> 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