On 9 September 2013 20:52, Christian Grobmeier <grobme...@gmail.com> wrote:
> Am 05.09.13 21:22, schrieb Lukasz Lenart:
>> 2013/9/5 Christian Grobmeier <grobme...@gmail.com>:
>>> Am 05.09.13 20:43, schrieb Lukasz Lenart:
>>>> Guys,
>>>>
>>>> are you serious? are you blaming OGNL? the hammer? 100% of
>>>> vulnerability related to OGNL was our - developers - fault. We did use
>>>> (and still do) the hammer in inappropriate way. Changing hammer is not
>>>> the solution!
>>> The hammer is stuck at Apache Commons. Nobody of us Struts devs has
>>> managed to make a release of it.
>>> Honestely OGNL codebase is a mess and we are short on man power.
>> Maybe a mess but anyway OGNL is very powerful - there was not enough
>> rumour but I think with S3 ahead is the way to go. I think what's left
>> to do is review all the TODOs and logging layer. TODOs are already on
>> my list.
> We may discuss this on the commons-dev list in depth. I already wrote 3
> messages on ognl last week.
>>
>>> Maybe we use it wrong. Then please lets fix it. Still the problem
>>> remains that we are using something which we don't control. It is also
>>> unlikely that we fix it in Commons-land the next time.
>> Nah... I have another pull-request to the old OGNL which was already
>> solved in the Commons-OGNL - it just shows that the OGNL code base is
>> very mature and ready to be released.
> For me it doesn't say anything. I mean, yeah, we ahve made some
> progress. But hey, we haven't ever made a release and its not 2 yrs or so.
>
> Anyway i am willing to help with the OGNL release. But I can't do it
> alone, because there are a few parts of OGNL i do not understand well.
> If you have some time, we can team up.
>
> My main concern: if we don't make a first release, it's getting more
> unlikely and unlikely. We need to step ahead now or we have a
> not-maintained component in code.
>
>>> To stick with your nice analogy - do we really need to solve a problems
>>> which requires a hammer? Or is something smaller efficient in the same
>>> way and maybe safer by default?
>> Maybe not, I don't know. But changing know hammer to unknown hammer
>> isn't the way to go - as for me :-)
> There is some truth in these wise words!
> :-)
>>
>>>> Things related to ${} or %{} should be clarified - %{} is called an
>>>> alternative syntax in the source ;-) It should be removed and we
>>>> should stick just to ${} - maybe it can be useful in XMLs as far I
>>>> know '$' isn't an allowed value - maybe something else can be used.
>>> This would fix one problem of many. But the more serious question is:
>>> how can we make Struts more secure? If we use it wrong, then lets try to
>>> make it good. I will interview Rene on the security manager option which
>>> was mentioned earlier in this thread.
>> How? Use the Java SecurityManager :-) Really, that was the answer of
>> one of the Tomcat's creator. If you want a fully secure Java based
>> application stick with what Java provides - don't invent the wheel!
> Yes, I meant the SecurityManager. Discussing with him on weekend, I
> understood
> the SecurityManager is a difficult beast. Also I understand better how
> deeply tied OGNL is with Struts - not only from frontend perspective.
> Not sure if we have the man power if we would move away from OGNL. Also
> the question remains, if we can improve things with another expression
> framework.
>
> We should separate the frontend discussion from the "general OGNL"
> discussion i think. For the frontend we can recommend easily something
> else than OGNL - tis a documentation topic.
>
> From a security standpoint we may have the man power to improve things.
> For example, if we manage to "disable static method" calls from OGNL we
> would have a win already. If we manage to restrict the path of OGNL we
> might have another win.
These security hardening proposals to OGNL sound like good starting points.
--
David Black / Security Engineer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
