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@xxxxxxxxx>
Sent: 21 March 2006 07:36
To: Stephen de Vries <stephen@xxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx
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]