ss please.
>
> Thanks
>
> Dave.
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Ted Husted
> Sent: 18 July 2007 12:24
> To: Struts Developers List
> Subject: Re: Preventing OGNL evaluations of user input (was Re: Strut
somewhere for
us to access please.
Thanks
Dave.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Ted Husted
Sent: 18 July 2007 12:24
To: Struts Developers List
Subject: Re: Preventing OGNL evaluations of user input (was Re: Struts 2
performance)
SVN
SVN.
* http://struts.apache.org/dev/builds.html
Unfortunately, the nightly builds aren't working right now, so to try
the changes the only alternative right now is to build the HEAD from
source.
-Ted.
On 7/18/07, Aram Mkhitaryan <[EMAIL PROTECTED]> wrote:
In the give link it is written that t
In the give link it is written that to get changes I have to get the latest
version.
Where can I get that version from? (fro SVN? or it is in 2.0.8?)
Thanks,
Aram
Aram Mkhitaryan
52, 25 Lvovyan, Yerevan 375000, Armenia
Mobile: +374 91 518456
E-mail: [EMAIL PROT
2007/7/17, Aram Mkhitaryan <[EMAIL PROTECTED]>:
I mean if I have myOgnlExpression(%{'property'+2}) in value stack,
according to the latest changes %{myOgnlExpression} will print
"%{'property'+2}"
but what if that expression is not client side defined, but site
administrator/developer defined an
I mean if I have myOgnlExpression(%{'property'+2}) in value stack,
according to the latest changes %{myOgnlExpression} will print
"%{'property'+2}"
but what if that expression is not client side defined, but site
administrator/developer defined and id should be executed???
but if we have %{eval(m
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
From: Dale Newfield <[EMAIL PROTECTED]>
Date: Tue, 17 Jul 2007 1:17:55 -0500
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
"Aram Mkhitaryan" <[EMAIL PROTECTED]
>I have to repeat my sugges
I 100% agree on this. I don't see any good reasons for evaluating the
strings entered from the client side of the app.
I donot agree,
maybe I have defined ognl expressions in a property file or db and I want to
evaluate those expressions,
but values of my variables will be considered as a strin
2007/7/16, Martin Cooper <[EMAIL PROTECTED]>:
On 7/16/07, Don Brown <[EMAIL PROTECTED]> wrote:
>
> I've added a security bulletin to our official Struts 2 documentation to
> begin to formalize this issue and its solution:
>
>
http://cwiki.apache.org/confluence/display/WW/S2-001+-+Remote+code+exp
On 7/16/07, Don Brown <[EMAIL PROTECTED]> wrote:
I've added a security bulletin to our official Struts 2 documentation to
begin to formalize this issue and its solution:
http://cwiki.apache.org/confluence/display/WW/S2-001+-+Remote+code+exploit+on+form+validation+error
This link doesn't appe
On 7/16/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
2007/7/16, Ian Roughley <[EMAIL PROTECTED]>:
>
> What do you define as "a user should not be allowed to execute such OGNL
> code!"? There are times that I want to call a static method and use the
> results. The problem to me (and as Don po
2007/7/16, Ian Roughley <[EMAIL PROTECTED]>:
What do you define as "a user should not be allowed to execute such OGNL
code!"? There are times that I want to call a static method and use the
results. The problem to me (and as Don pointed out), is that there is
malicious code stored in the datab
What do you define as "a user should not be allowed to execute such OGNL
code!"? There are times that I want to call a static method and use the
results. The problem to me (and as Don pointed out), is that there is
malicious code stored in the database that was entered by users - and is
a typ
What about the change of order of evaluation ? Am I correct ?
Don't think it's important however...
Il giorno 16/lug/07, alle ore 17:03, Don Brown ha scritto:
I've added a security bulletin to our official Struts 2
documentation to
begin to formalize this issue and its solution:
http://cwik
I've added a security bulletin to our official Struts 2 documentation to
begin to formalize this issue and its solution:
http://cwiki.apache.org/confluence/display/WW/S2-001+-+Remote+code+exploit+on+form+validation+error
Don
On 7/17/07, Don Brown <[EMAIL PROTECTED]> wrote:
The patch I commited
The patch I commited is based on the original loopcount patch, but fixes the
problem where it wouldn't evaluate all non-recursive expressions.
Therefore, the issue has been fixed and all tests still pass. I agree that
we should re-evaluate our usage of ognl down the road, but I believe the
commit
>
>> > > As has been said the current fix is not ideal. The changes
>> that have
>> > > been made to params interceptor mean that the functionality in
>> > > ParamsInterceptor and ParamFilterInterceptor are now very
>> similar,
>> > > except o
Il giorno 16/lug/07, alle ore 16:46, Antonio Petrelli ha scritto:
2007/7/16, Ing. Andrea Vettori <[EMAIL PROTECTED]>:
I suggested the value can be parametrized so if one
known he use complex expression can use a higher value. (b) is solved
using loopCount=1 by default when dealing with user i
2007/7/16, Ing. Andrea Vettori <[EMAIL PROTECTED]>:
I suggested the value can be parametrized so if one
known he use complex expression can use a higher value. (b) is solved
using loopCount=1 by default when dealing with user input.
OK! Thank you I think I got the point.
So you are saying th
The "Musachy" patch that prevents the parameters to have the pattern %
{*} works great as a workaround (and i'm using that in my e-commerce
site where I found this problem).
I think that the final patch should address the unlikely but possible
case when the user has to enter (or we need to p
Probably there was a misunderstanding Andrea.
First of all, are we talking about:
1. the "preliminar" patch, that at least prevents remote exploit by
disallowing malicious code,
or
2. the final patch? In this case, the final patch, is "1." or a patch that,
as I stated before, removes completely O
Antonio,
the recursion solve the problem because after the first "step" you
are exposing to the remote exploit. The first evaluation step is secure.
If you have %{foo} somewhere and you evaluate it if the property foo
does not contain an expression you are safe. If it contains an
expressi
TED]> wrote:
>> > >
>> > > As has been said the current fix is not ideal. The changes
>> that have
>> > > been made to params interceptor mean that the functionality in
>> > > ParamsInterceptor and ParamFilterInterceptor are now very
>> similar,
2007/7/16, Ing. Andrea Vettori <[EMAIL PROTECTED]>:
What about expression like "%{foo} %{bar}" that work with the current
version but don't work using the loopCounter patch ?
I don't think we need them but who knows...
I think that recursion is a false problem: it's up to the developer to
c
y are crucial to security?
With this
> > fix there is the danger now that as soon as anyone adds in
there own
> > "excludePattern" they can remove the default which is
preventing the
> > ognl hack, without realising the problem they are creating.
> >
> >
ing to combine
> > > these now that it is apparent they are crucial to security? With
this
> > > fix there is the danger now that as soon as anyone adds in there own
> > > "excludePattern" they can remove the default which is preventing the
> > > ognl hac
ucial to security? With this
> > fix there is the danger now that as soon as anyone adds in there own
> > "excludePattern" they can remove the default which is preventing the
> > ognl hack, without realising the problem they are creating.
> >
> >
> > - Or
n Brown" <[EMAIL PROTECTED]>
> To: "Struts Developers List"
> Date: Mon, 16 Jul 2007 21:49:15 +1000
> Subject: Re: Preventing OGNL evaluations of user input (was Re: Struts 2
> performance)
>
> Continuing in dev@ ...
>
> On 7/16/07, Aram M
2007/7/16, Aram Mkhitaryan <[EMAIL PROTECTED]>:
everywhere in s2 tags the user submitted values should not be evaluated
till
it is not requested
with a method call like "eval(ognlString)" otherwise it should not work
I disagree. Whatever the user types in the fields, it MUST NOT be evaluated
As a user I would like to know exactly that everything is clear and secure.
From my point of view I do not need to know about parameter filters and
stuff like that.
If it is not changing much, it would be nice to have the following behavior
:
everywhere in s2 tags the user submitted values sh
xcludePattern" they can remove the default which is preventing the
ognl hack, without realising the problem they are creating.
- Original message -
From: "Don Brown" <[EMAIL PROTECTED]>
To: "Struts Developers List"
Date: Mon, 16 Jul 2007 21:49:15 +1000
Su
Brown" <[EMAIL PROTECTED]>
To: "Struts Developers List"
Date: Mon, 16 Jul 2007 21:49:15 +1000
Subject: Re: Preventing OGNL evaluations of user input (was Re: Struts 2
performance)
Continuing in dev@ ...
On 7/16/07, Aram Mkhitaryan <[EMAIL PROTECTED]> wrote:
> Don, coul
Continuing in dev@ ...
On 7/16/07, Aram Mkhitaryan <[EMAIL PROTECTED]> wrote:
Don, could you please send the subject to continue the discussion in?
Should we use [EMAIL PROTECTED]
Thanks,
Aram
Aram Mkhitaryan
52, 25 Lvovyan, Yerevan 375000, Armenia
Mobile: +37
If your application is displaying user input without checking for
malicious code, you have a problem whether Struts 2 evaluations ognl
expressions or not.This is how the majority of Cross-Site
Scripting (XSS) [1] attacks work, tricking the user into visiting a
page that the attacker has placed
34 matches
Mail list logo
