struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukasz Lenart <lukaszlen...@apache.org>
Subject Re: [struts-dev] Re: Ultimate way to solve problems with Ognl
Date Mon, 05 May 2014 05:16:59 GMT
Ognl gives a simple way to check if access to given method/class is
allowed - MemberAccess interface - and Struts is using it lready via
ParametersInterceptor and SecurityMemberAccess class. Right now I'm
extending SecurityMemberAccess - it looks more appropriate than
SecurityManager, ie.

public boolean isAccessible(Map context, Object target, Member member,
String propertyName);

As you see there is more information provided to base on during
judging if method is accessible or not.


Regards
-- 
Ɓukasz
+ 48 606 323 122 http://www.lenart.org.pl/

2014-05-04 19:57 GMT+02:00 Jason Pyeron <jpyeron@pdinc.us>:
>> -----Original Message-----
>> From: Lukasz Lenart
>> Sent: Sunday, May 04, 2014 4:24
>>
>> Yeah, me too - the same logic will be used to call actions and
>> methods. And with current version I can set ".*" as accepted params
>> pattern and still you cannot access anything which isn't allowed ;-)
>>
>> Thanks for the tip! I think I will add "struts.excludedPackages" with
>> regex support to excluded all the classes in given set of packages,
>> eg. "java.lang.*", "ognl.*"
>
> Security manager pattern? I think a default security manager should be in place
> for OGNL and that it would have the purview of what is not allowed to be loaded.
> Architecturally it seems the most simplistic.
>
> As to the configurability of it:
>
> 1. includes
> - single class
> - single package
> - package and children
> - regex
> 2. Excludes
> - single class
> - single package
> - package and children
> - regex
> 3. Default rule: allow/deny
>
>>
>>
>> Regards
>> --
>> Lukasz
>> + 48 606 323 122 http://www.lenart.org.pl/
>>
>> 2014-05-04 10:17 GMT+02:00  <Michael.Hintenaus@silbergrau.com>:
>> > Hi,
>> >
>> > I also think it's better to handle this on a central point
>> (instead of the interceptors).
>> >
>> > I would also exclude java.lang.Thread
>> >
>> > Regards
>> >
>> > Ing. Michael Hintenaus
>> > silbergrau Consulting & Software GmbH
>> > http://www.silbergrau.com
>> >
>> >> Am 03.05.2014 um 17:56 schrieb "Lukasz Lenart"
>> <lukaszlenart@apache.org>:
>> >>
>> >> Hi,
>> >>
>> >> I'm working on solution to close the security gap in how
>> we use Ognl
>> >> inside Struts. The changes are here [1] and based on idea
>> to exclude
>> >> certain classes from evaluation, eg. Object, Runtime.
>> >>
>> >> What do you think about that? And what other class should
>> I exclude?
>> >> I'm planning to have it configurable but the default provided by
>> >> framework must be strong.
>> >>
>> >> [1] https://github.com/apache/struts/pull/11
>
> This begs the question (only spent a minute reviewing) should the call to
> com.sun.GoingToHackYourBox be a silent denial or a "big" stacktrace error?
>
>> >>
>> >>
>> >> Regards
>> >> --
>> >> Lukasz
>> >> + 48 606 323 122 http://www.lenart.org.pl/
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>
>
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> -                                                               -
> - Jason Pyeron                      PD Inc. http://www.pdinc.us -
> - Principal Consultant              10 West 24th Street #100    -
> - +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
> -                                                               -
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> This message is copyright PD Inc, subject to license 20080407P00.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message