[WEB SECURITY] How to Create Secure Web Applications with Struts

Pilon Mntry pilonmntry at yahoo.com
Wed Mar 22 10:21:08 EST 2006


 I'm having an half audit half pen test because of
which they don't let me read their struts xml files or
any other conf. files for that matter but I have
access to their test env. with fake user credentials
and some more information. :(
 But, hey, that would be great and I think helpful for
the community, too.

-pilon

--- Dinis Cruz <dinis at ddplus.net> wrote:

> Pilon, how are you analysing the struts xml files?
> 
> I wrote a quick xslt transformation that allowed me
> to see them in a nice format (in html tables)
> 
> Let me know if you think that will be usefull to you
> and I will post in online
> 
> Dinis
> 
> ----------------------------------------
> From: Pilon Mntry <pilonmntry at yahoo.com>
> Sent: 21 March 2006 09:40
> To: dinis.cruz at ddplus.net
> Subject: Re: [WEB SECURITY] How to Create Secure Web
> Applications with Struts 
> 
> Hi Dinis,
> 
> > if the presentation is on the client side (ala 
> > AJAX ...
> 
> Well, when I wrote "presentation layer" I meant the
> one at the server side (since the issue was Struts),
> but of course, you are right that when AJAX or alike
> is employed then there remains one (secure)
> validation.
> 
> > For example, I did an audit to a struts based Java
> > App which had massive Authorization problems ...
> 
> And I'm doing one right now :). When a developer
> uses
> Struts Validator on a parameter with positive
> approach(let's say [a-zA-Z0-9]), then it would be
> hard
> to convince him to do another validation in his
> business logic for SQL injection.
> 
> -pilon
> 
> --- Dinis Cruz  wrote:
> 
> > Pilon, when you say:
> > 
> > > However, with this approach when positive
> > validation (whitelist) is used, there probably
> will
> > be
> > > unnecessary double validation: one in
> presentation
> > layer and the other in business layer. But I
> guess,
> > > that's one should pay for extensibility and
> > security sake. 
> > 
> > if the presentation is on the client side (ala
> > AJAX), then there is only one security validation
> > (since the one done at client slide has no
> security
> > relevance and doesn't count :)
> > 
> > Also note that doing data validation very away
> from
> > the business logic (i.e. the presentation layer)
> can
> > introduce massive exploitable blind spots
> > 
> > For example, I did an audit to a struts based Java
> > App which had massive Authorization problems (and
> > some data validation issues too)
> > 
> > Dinis Cruz
> > Owasp .Net Project
> > www.owasp.net
> > 
> > ----------------------------------------
> > From: Pilon Mntry 
> > Sent: 21 March 2006 07:36
> > To: Stephen de Vries 
> > Subject: Re: [WEB SECURITY] How to Create Secure
> Web
> > Applications with Struts 
> > 
> > > It may not be a big issue, but I think it's
> > > important to understand 
> > > how choosing the web tier as a security provider
> > > could impact the 
> > > extensibility of the app down the line.
> > 
> > Nice comment. In owasp guide it goes like this;
> > 
> > "...the web / presentation tier should validate
> for
> > web related issues, persistence layers should
> > validate
> > for persistence issues such as SQL / HQL
> injection,
> > directory lookups should check for LDAP injection,
> > and
> > so on."
> > 
> > However, with this approach when positive
> validation
> > (whitelist) is used, there probably will be
> > unnecessary double validation: one in presentation
> > layer and the other in business layer. But I
> guess,
> > that's one should pay for extensibility and
> security
> > sake. 
> > 
> > And this is for data validation only.
> Authorization
> > is
> > another issue...
> > 
> > And nice article by the way.
> > 
> > -pilon
> > 
> > --- Stephen de Vries wrote:
> > 
> > > 
> > > Great article!
> > > 
> > > It did make me think of a particular
> architectural
> > > issue which seems 
> > > to be cropping up more and more; that is, the
> > impact
> > > that 
> > > implementing security in the web tier has on the
> > > future extensibility 
> > > of the app.
> > > 
> > > For applications that were designed as web apps
> > and
> > > will continue to 
> > > only be web apps for the rest of their lives,
> this
> > > shouldn't impact 
> > > much on the extensibility of the apps. If the
> > > validation rules or 
> > > access control requirements change, these can
> > easily
> > > be changed in 
> > > the web tier (and as you've shown Struts makes
> it
> > > really easy, 
> > > because it's all declarative).
> > > But if the application needs to be extensible,
> > e.g.
> > > must have a fat 
> > > client down the road or must expose web
> services,
> > > then any security 
> > > implemented in the web tier would have to be
> > > re-implemented in all 
> > > the other facades. To be truly extensible
> > > applications should 
> > > implement security functionality in the business
> > > tier so that any 
> > > changes to the presentation technology (or new
> > > technologies) don't 
> > > impact the core functionality. E.g. for classic
> > > J2EE technologies 
> > > this would mean implementing access control on
> the
> > > EJB's themselves 
> > > rather than in the web tier. This is also the
> > > approach taken by the 
> > > Spring framework: both access control and input
> > > validation are tied 
> > > to the beans that form the middle tier, not the
> > > presentation.
> > > 
> > > It may not be a big issue, but I think it's
> > > important to understand 
> > > how choosing the web tier as a security provider
> > > could impact the 
> > > extensibility of the app down the line.
> > > 
> > > 2p
> > > 
> > > Stephen
> > > 
> > > 
> > > On 20 Mar 2006, at 02:44,
> bugtraq at cgisecurity.net
> > > wrote:
> > > 
> > > > "This article will focus on developing secure
> > Web
> > > applications with 
> > > > the popular Java framework Struts.
> > > > It will detail a set of best practices using
> the
> > > included security 
> > > > mechanisms. The first section will
> > > > provide an overview of both Struts and Web
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/



More information about the websecurity mailing list