[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] How to Create Secure Web Applications with Struts
- From: Dinis Cruz <dinis@xxxxxxxxxx>
- Subject: Re: [WEB SECURITY] How to Create Secure Web Applications with Struts
- Date: Tue, 21 Mar 2006 08:39:07 -0500
------_SmarterMail_NextPart_8254788573504135
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Pilon, when you say:=0D=0A=0D=0A > However, with this approach when positiv=
e validation (whitelist) is used, there probably will be=0D=0A> unnecessary=
double validation: one in presentation layer and the other in business lay=
er. But I guess,=0D=0A> that's one should pay for extensibility and securit=
y sake. =0D=0A=0D=0Aif the presentation is on the client side (ala AJAX), t=
hen there is only one security validation (since the one done at client sli=
de has no security relevance and doesn't count :)=0D=0A=0D=0AAlso note that=
doing data validation very away from the business logic (i.e. the presenta=
tion layer) can introduce massive exploitable blind spots=0D=0A=0D=0AFor ex=
ample, I did an audit to a struts based Java App which had massive Authoriz=
ation problems (and some data validation issues too)=0D=0A=0D=0ADinis Cruz=
=0D=0AOwasp .Net Project=0D=0Awww.owasp.net=0D=0A=0D=0A--------------------=
--------------------=0D=0AFrom: Pilon Mntry <pilonmntry@yahoo.com>=0D=0ASen=
t: 21 March 2006 07:36=0D=0ATo: Stephen de Vries <stephen@corsaire.com>=0D=
=0ASubject: Re: [WEB SECURITY] How to Create Secure Web Applications with S=
truts =0D=0A=0D=0A> It may not be a big issue, but I think it's=0D=0A> impo=
rtant to understand =0D=0A> how choosing the web tier as a security provide=
r=0D=0A> could impact the =0D=0A> extensibility of the app down the line.=
=0D=0A=0D=0ANice comment. In owasp guide it goes like this;=0D=0A=0D=0A"...=
the web / presentation tier should validate for=0D=0Aweb related issues, pe=
rsistence layers should validate=0D=0Afor persistence issues such as SQL / =
HQL injection,=0D=0Adirectory lookups should check for LDAP injection, and=
=0D=0Aso on."=0D=0A=0D=0AHowever, with this approach when positive validati=
on=0D=0A(whitelist) is used, there probably will be=0D=0Aunnecessary double=
validation: one in presentation=0D=0Alayer and the other in business layer=
. But I guess,=0D=0Athat's one should pay for extensibility and security=0D=
=0Asake. =0D=0A=0D=0AAnd this is for data validation only. Authorization is=
=0D=0Aanother issue...=0D=0A=0D=0AAnd nice article by the way.=0D=0A=0D=0A-=
pilon=0D=0A=0D=0A--- Stephen de Vries wrote:=0D=0A=0D=0A> =0D=0A> Great ar=
ticle!=0D=0A> =0D=0A> It did make me think of a particular architectural=0D=
=0A> issue which seems =0D=0A> to be cropping up more and more; that is, th=
e impact=0D=0A> that =0D=0A> implementing security in the web tier has on t=
he=0D=0A> future extensibility =0D=0A> of the app.=0D=0A> =0D=0A> For appli=
cations that were designed as web apps and=0D=0A> will continue to =0D=0A> =
only be web apps for the rest of their lives, this=0D=0A> shouldn't impact =
=0D=0A> much on the extensibility of the apps. If the=0D=0A> validation rul=
es or =0D=0A> access control requirements change, these can easily=0D=0A> b=
e changed in =0D=0A> the web tier (and as you've shown Struts makes it=0D=
=0A> really easy, =0D=0A> because it's all declarative).=0D=0A> But if the =
application needs to be extensible, e.g.=0D=0A> must have a fat =0D=0A> cli=
ent down the road or must expose web services,=0D=0A> then any security =0D=
=0A> implemented in the web tier would have to be=0D=0A> re-implemented in =
all =0D=0A> the other facades. To be truly extensible=0D=0A> applications s=
hould =0D=0A> implement security functionality in the business=0D=0A> tier =
so that any =0D=0A> changes to the presentation technology (or new=0D=0A> t=
echnologies) don't =0D=0A> impact the core functionality. E.g. for classic=
=0D=0A> J2EE technologies =0D=0A> this would mean implementing access contr=
ol on the=0D=0A> EJB's themselves =0D=0A> rather than in the web tier. This=
is also the=0D=0A> approach taken by the =0D=0A> Spring framework: both ac=
cess control and input=0D=0A> validation are tied =0D=0A> to the beans that=
form the middle tier, not the=0D=0A> presentation.=0D=0A> =0D=0A> It may n=
ot be a big issue, but I think it's=0D=0A> important to understand =0D=0A> =
how choosing the web tier as a security provider=0D=0A> could impact the =
=0D=0A> extensibility of the app down the line.=0D=0A> =0D=0A> 2p=0D=0A> =
=0D=0A> Stephen=0D=0A> =0D=0A> =0D=0A> On 20 Mar 2006, at 02:44, bugtraq@cg=
isecurity.net=0D=0A> wrote:=0D=0A> =0D=0A> > "This article will focus on de=
veloping secure Web=0D=0A> applications with =0D=0A> > the popular Java fra=
mework Struts.=0D=0A> > It will detail a set of best practices using the=0D=
=0A> included security =0D=0A> > mechanisms. The first section will=0D=0A> =
> provide an overview of both Struts and Web=0D=0A> application security as=
=0D=0A> > a context for discussion. Each=0D=0A> > subsequent section will =
focus on a specific=0D=0A> security principle and =0D=0A> > discuss how Str=
uts can be leveraged=0D=0A> > to address it."=0D=0A> >=0D=0A> > http://be.s=
ys-con.com/read/192434.htm=0D=0A> >=0D=0A> > - zeno=0D=0A> > http://www.cgi=
security.com/ Application Security=0D=0A> News, and more!=0D=0A> > http://w=
ww.cgisecurity.com/index.rss [RSS Feed]=0D=0A> >=0D=0A> >=0D=0A>=0D=0A-----=
----------------------------------------------------------------=0D=0A> > T=
he Web Security Mailing List=0D=0A> > http://www.webappsec.org/lists/websec=
urity/=0D=0A> >=0D=0A> > The Web Security Mailing List Archives=0D=0A> >=0D=
=0A> http://www.webappsec.org/lists/websecurity/archive/=0D=0A> >=0D=0A> =
=0D=0A> -- =0D=0A> Stephen de Vries=0D=0A> Corsaire Ltd=0D=0A> E-mail: step=
hen@corsaire.com=0D=0A> Tel: +44 1483 226014=0D=0A> Fax: +44 1483 226068=0D=
=0A> Web: http://www.corsaire.com=0D=0A> =0D=0A> =0D=0A> =0D=0A> =0D=0A> =
=0D=0A> =0D=0A>=0D=0A------------------------------------------------------=
-------------------=0D=0A> This List Sponsored by: SpiDynamics=0D=0A> =0D=
=0A> ALERT: "How A Hacker Launches A Web Application=0D=0A> Attack!" =0D=0A=
> Step-by-Step - SPI Dynamics White Paper=0D=0A> Learn how to defend agains=
t Web Application Attacks=0D=0A> with real-world =0D=0A> examples of recent=
hacking methods such as: SQL=0D=0A> Injection, Cross Site =0D=0A> Scriptin=
g and Parameter Manipulation=0D=0A> =0D=0A>=0D=0Ahttps://download.spidynami=
cs.com/1/ad/web.asp?Campaign_ID=3D701300000003gRl=0D=0A>=0D=0A-------------=
-------------------------------------------------------------=0D=0A> =0D=0A=
> =0D=0A=0D=0A__________________________________________________=0D=0ADo Yo=
u Yahoo!?=0D=0ATired of spam? Yahoo! Mail has the best spam protection arou=
nd =0D=0Ahttp://mail.yahoo.com =0D=0A=0D=0A--------------------------------=
-------------------------------------=0D=0AThe Web Security Mailing List=0D=
=0Ahttp://www.webappsec.org/lists/websecurity/=0D=0A=0D=0AThe Web Security =
Mailing List Archives=0D=0Ahttp://www.webappsec.org/lists/websecurity/archi=
ve/=0D=0A=0D=0A
------_SmarterMail_NextPart_8254788573504135
Content-Type: text/html;
charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
<font face=3D"arial" size=3D"2">Pilon, when you say:<br /><br /></font>>=
However, with this approach when positive validation (whitelist) is used, =
there probably will be<br />> unnecessary double validation: one in pres=
entation layer and the other in business layer. But I guess,<br />> that=
's one should pay for extensibility and security sake. <br /><font face=3D"=
arial" size=3D"2"><br />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 :)<br /><br />Also note =
that doing data validation very away from the business logic (i.e. the pres=
entation layer) can introduce massive exploitable blind spots<br /><br />Fo=
r example, I did an audit to a struts based Java App which had massive Auth=
orization problems (and some data validation issues too)<br /><br />Dinis C=
ruz<br />Owasp .Net Project<br />www.owasp.net<br /></font><font face=3D"Ta=
homa, Arial, Sans-Serif" size=3D"2"><hr align=3D"center" size=3D"2" width=
=3D"100%" /><b>From</b>: Pilon Mntry <pilonmntry@yahoo.com><br /><b>S=
ent</b>: 21 March 2006 07:36<br /><b>To</b>: Stephen de Vries <stephen@c=
orsaire.com><br /><b>Subject</b>: Re: [WEB SECURITY] How to Create Secur=
e Web Applications with Struts</font><br /><br /><br /><br />> It may no=
t be a big issue, but I think it's<br />> important to understand <br />=
> how choosing the web tier as a security provider<br />> could impac=
t the <br />> extensibility of the app down the line.<br /><br />Nice co=
mment. In owasp guide it goes like this;<br /><br />"...the web / presentat=
ion tier should validate for<br />web related issues, persistence layers sh=
ould validate<br />for persistence issues such as SQL / HQL injection,<br /=
>directory lookups should check for LDAP injection, and<br />so on."<br /><=
br />However, with this approach when positive validation<br />(whitelist) =
is used, there probably will be<br />unnecessary double validation: one in =
presentation<br />layer and the other in business layer. But I guess,<br />=
that's one should pay for extensibility and security<br />sake. <br /><br /=
>And this is for data validation only. Authorization is<br />another issue.=
..<br /><br />And nice article by the way.<br /><br />-pilon<br /><br />---=
Stephen de Vries <stephen@corsaire.com> wrote:<br /><br />> <br />> =
Great article!<br />> <br />> It did make me think of a particular ar=
chitectural<br />> issue which seems <br />> to be cropping up more a=
nd more; that is, the impact<br />> that <br />> implementing securit=
y in the web tier has on the<br />> future extensibility <br />> of t=
he app.<br />> <br />> For applications that were designed as web app=
s and<br />> will continue to <br />> only be web apps for the rest o=
f their lives, this<br />> shouldn't impact <br />> much on the exten=
sibility of the apps. If the<br />> validation rules or <br />> acces=
s control requirements change, these can easily<br />> be changed in <br=
/>> the web tier (and as you've shown Struts makes it<br />> really =
easy, <br />> because it's all declarative).<br />> But if the applic=
ation needs to be extensible, e.g.<br />> must have a fat <br />> cli=
ent down the road or must expose web services,<br />> then any security =
<br />> implemented in the web tier would have to be<br />> re-implem=
ented in all <br />> the other facades. To be truly extensible<br />>=
applications should <br />> implement security functionality in the bus=
iness<br />> tier so that any <br />> changes to the presentation tec=
hnology (or new<br />> technologies) don't <br />> impact the core fu=
nctionality. E.g. for classic<br />> J2EE technologies <br />> this w=
ould mean implementing access control on the<br />> EJB's themselves <br=
/>> rather than in the web tier. This is also the<br />> approach ta=
ken by the <br />> Spring framework: both access control and input<br />=
> validation are tied <br />> to the beans that form the middle tier,=
not the<br />> presentation.<br />> <br />> It may not be a big i=
ssue, but I think it's<br />> important to understand <br />> how cho=
osing the web tier as a security provider<br />> could impact the <br />=
> extensibility of the app down the line.<br />> <br />> 2p<br />&=
gt; <br />> Stephen<br />> <br />> <br />> On 20 Mar 2006, at 0=
2:44, bugtraq@cgisecurity.net<br />> wrote:<br />> <br />> > "T=
his article will focus on developing secure Web<br />> applications with=
<br />> > the popular Java framework Struts.<br />> > It will =
detail a set of best practices using the<br />> included security <br />=
> > mechanisms. The first section will<br />> > provide an over=
view of both Struts and Web<br />> application security as <br />> &g=
t; a context for discussion. Each<br />> > subsequent section will fo=
cus on a specific<br />> security principle and <br />> > discuss =
how Struts can be leveraged<br />> > to address it."<br />> ><b=
r />> > http://be.sys-con.com/read/192434.htm<br />> ><br />>=
; > - zeno<br />> > http://www.cgisecurity.com/ Application Securi=
ty<br />> News, and more!<br />> > http://www.cgisecurity.com/inde=
x.rss [RSS Feed]<br />> ><br />> ><br />><br />-------------=
--------------------------------------------------------<br />> > The=
Web Security Mailing List<br />> > http://www.webappsec.org/lists/we=
bsecurity/<br />> ><br />> > The Web Security Mailing List Arch=
ives<br />> ><br />> http://www.webappsec.org/lists/websecurity/ar=
chive/<br />> ><br />> <br />> -- <br />> Stephen de Vries<b=
r />> Corsaire Ltd<br />> E-mail: stephen@corsaire.com<br />> Tel:=
+44 1483 226014<br />> Fax: +44 1483 226068<br />> Web: http://www.c=
orsaire.com<br />> <br />> <br />> <br />> <br />> <br />>=
; <br />><br />---------------------------------------------------------=
----------------<br />> This List Sponsored by: SpiDynamics<br />> <b=
r />> ALERT: "How A Hacker Launches A Web Application<br />> Attack!"=
<br />> Step-by-Step - SPI Dynamics White Paper<br />> Learn how to =
defend against Web Application Attacks<br />> with real-world <br />>=
examples of recent hacking methods such as: SQL<br />> Injection, Cross=
Site <br />> Scripting and Parameter Manipulation<br />> <br />><=
br />https://download.spidynamics.com/1/ad/web.asp?Campaign_ID=3D7013000000=
03gRl<br />><br />------------------------------------------------------=
--------------------<br />> <br />> <br /><br /><br />_______________=
___________________________________<br />Do You Yahoo!?<br />Tired of spam?=
Yahoo! Mail has the best spam protection around <br />http://mail.yahoo.co=
m <br /><br />-------------------------------------------------------------=
--------<br />The Web Security Mailing List<br />http://www.webappsec.org/l=
ists/websecurity/<br /><br />The Web Security Mailing List Archives<br />ht=
tp://www.webappsec.org/lists/websecurity/archive/<br /><br /><br /></stephe=
n@corsaire.com>
------_SmarterMail_NextPart_8254788573504135--
Brought to you by http://www.webappsec.org