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

Stephen de Vries stephen at corsaire.com
Tue Mar 21 10:45:33 EST 2006


On 21 Mar 2006, at 21:39, Pilon Mntry wrote:

<snip>
>
>> 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.

I think it's necessary to make a distinction between "validation" and  
"meta-character escaping" since they are really two distinct exercises.

1. Data validation belongs to the domain model (even if it is defined  
in the web tier) and is the process of only accepting characters  
which are valid for that data set.  So during data validation you'd  
have a whitelist of acceptable characters.  The choice of these  
characters should be based only on what makes sense for the data  
model - at this stage the developer shouldn't be thinking about sql  
injection or xss or any other injection attack.  For example, if a  
single quote character is a valid character for a surname, which it  
is, then it should be permitted, but a % should be denied.

2. Now, just before the data is processed, all meta-characters for  
the specific processing context that is acting on the data needs to  
be escaped.  Which is what I believe the OWASP guide refers to  
(except it calls it validation, instead of escaping).  SQL characters  
should be escaped before database queries are made and LDAP meta- 
characters should be escaped before LDAP queries are made.  Whether  
characters in the data are valid for the model or not should be  
handled by step 1. above, and not by the function performing the  
processing.  All it does is escape all the meta-characters it knows  
about.

So there isn't really a duplication of validation functions in the  
various tiers, each component is simply taking care of its own  
house.  The domain only accepts data that is valid for itself but is  
unaware of any meta-characters.  And the contexts that process the  
data (such as Data Access Objects) know how and what to escape before  
processing the data but don't care if the data is appropriate for the  
model or not.

Stephen


>
> --- Dinis Cruz <dinis at ddplus.net> 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 <pilonmntry at yahoo.com>
>> Sent: 21 March 2006 07:36
>> To: Stephen de Vries <stephen at corsaire.com>
>> 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
>>> application security as
>>>> a context for discussion. Each
>>>> subsequent section will focus on a specific
>>> security principle and
>>>> discuss how Struts can be leveraged
>>>> to address it."
>>>>
>>>> http://be.sys-con.com/read/192434.htm
>>>>
>>>> - zeno
>>>> http://www.cgisecurity.com/ Application Security
>>> News, and more!
>>>> http://www.cgisecurity.com/index.rss [RSS Feed]
>>>>
>>>>
>>>
>>
> ---------------------------------------------------------------------
>>>> The Web Security Mailing List
>>>> http://www.webappsec.org/lists/websecurity/
>>>>
>>>> The Web Security Mailing List Archives
>>>>
>>>
>> http://www.webappsec.org/lists/websecurity/archive/
>>>>
>>>
>>> -- 
>>> Stephen de Vries
>>> Corsaire Ltd
>>> E-mail: stephen at corsaire.com
>>> Tel: +44 1483 226014
>>> Fax: +44 1483 226068
>>> Web: http://www.corsaire.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------- 
> ---
>>> This List Sponsored by: SpiDynamics
>>>
>>> ALERT: "How A Hacker Launches A Web Application
>>> Attack!"
>>> Step-by-Step - SPI Dynamics White Paper
>>> Learn how to defend against Web Application
>> Attacks
>>> with real-world
>>> examples of recent hacking methods such as: SQL
>>> Injection, Cross Site
>>> Scripting and Parameter Manipulation
>>>
>>>
>>
> https://download.spidynamics.com/1/ad/web.asp? 
> Campaign_ID=701300000003gRl
>>>
>>
> ---------------------------------------------------------------------- 
> ----
>>>
>>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam
>> protection
> === 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/
>

-- 
Stephen de Vries
Corsaire Ltd
E-mail: stephen at corsaire.com
Tel:	+44 1483 226014
Fax: 	+44 1483 226068
Web: 	http://www.corsaire.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