I personally really like OGNL again this is in the view layer (which most of this discussion is not concerned with). However if any of you that have not watched the presentation of what EL3 offers you probably should: http://www.youtube.com/watch?v=JEKpRjXL06w
But even with respect to the view layer, OGNL will need some revitalization. It's true that OGNL has had lambda expression for some time, I don't think many people took them seriously, myself included, but having seen how EL3 makes good use of them, shows embracing it makes sense (see video above if you haven't yet). What this means is that even in the view layer OGNL is going to need some work in the near future or it will offer no advantage over the EL most people will already be familiar with. Also the EL3 presentation shows that they've put more effort into decoupling EL from the container, they even provide a convenient EL evaluator out of the box! So there should be a way to use it with freemarker/velocity which is a must as long as JSPs are tied to the container. I really like how the tiles project handles EL in their definitions (they support EL, MVEL, OGNL, even wildcards/regex, you can even provide others!): http://tiles.apache.org/2.2/framework/tutorial/advanced/el-support.html They just use a simple prefix mechanism, as you can see on the linked tiles page. Security is an important topic but with the next iteration of JEE EL, I don't see any advantage to using OGNL once EL3 is in main stream use. On Wed, Sep 4, 2013 at 10:20 AM, Christian Grobmeier <grobme...@gmail.com>wrote: > Am 04.09.13 18:15, schrieb Paul Benedict: > > Thank you Cameron for providing this list. I appreciate it. It helped me > > alot. > +1 > > Christian, what do you mean by "sandboxing" the ValueStack? > Ah i am not sure if I express this well because I have just recently > digged deeper into OGNL/Struts. > > As I understand it, OGNL is meant to evaluate against the ValueStack > mainly (referring to f.e. Struts-Tags). Now it looks as OGNL can access > things outside this value stack which is bad. What, if OGNL could only > access things inside the value stack. > > Thinking again, I don't have an idea if this is possible or if this is a > solution for the problem. > > > > > > > > On Wed, Sep 4, 2013 at 10:44 AM, Cameron Morris <cmor...@part.net> > wrote: > > > >> Here is a Struts2 - OGNL vulnerability breakdown. > >> > >> View based OGNL Vulns: > >> - S2-001 <http://struts.apache.org/release/2.3.x/docs/s2-001.html> > >> - S2-013 <http://struts.apache.org/release/2.3.x/docs/s2-013.html> > >> - S2-014 <http://struts.apache.org/release/2.3.x/docs/s2-014.html> > >> > >> Non-View based OGNL Vuln: > >> - S2-003 <http://struts.apache.org/release/2.3.x/docs/s2-003.html> > >> - S2-005 <http://struts.apache.org/release/2.3.x/docs/s2-005.html> > >> - S2-007 <http://struts.apache.org/release/2.3.x/docs/s2-007.html> > >> - S2-009 <http://struts.apache.org/release/2.3.x/docs/s2-009.html> > >> - S2-012 <http://struts.apache.org/release/2.3.x/docs/s2-012.html> > >> - S2-015 <http://struts.apache.org/release/2.3.x/docs/s2-015.html> > >> - S2-016 <http://struts.apache.org/release/2.3.x/docs/s2-016.html> > >> > >> > >> On Wed, Sep 4, 2013 at 9:31 AM, Paul Benedict <pbened...@apache.org> > >> wrote: > >> > >>> Christian, as I said, I am OK with the view laying using OGNL. If JSPs > >> are > >>> using that, I see no problem. But I should ask if the majority of > >>> vulnerabilities are from the view layer or from the > processor/controller > >>> layer? > >>> > >>> > >>> On Wed, Sep 4, 2013 at 10:20 AM, Christian Grobmeier < > >> grobme...@gmail.com > >>>> wrote: > >>>> Am 04.09.13 16:34, schrieb Dave Newton: > >>>>> I'd looked in to replacing OGNL with MVEL, including the templating, > >>> but > >>>> it > >>>>> entailed a fairly extensive effort. > >>>>> > >>>>> Not saying it isn't worth it; personally I'd like to see a few other > >>>>> options and a simplification of the templates (and potential > >> speedups). > >>>> I found Struts-Tags often rely on the com.opensymphony.xwork2.ognl > >>>> package (accessing the valuestack). My guess is, everything which > >> access > >>>> the value stack is done with with OGNL. I think Validation bases on > >> OGNL > >>>> too. > >>>> > >>>> > >>>> > >>>>> Dave > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Sep 4, 2013 at 10:21 AM, Paul Benedict <pbened...@apache.org > >>>> wrote: > >>>>>> Isn't it already "decoupled" since OGNL is a separate project? I > >> mean, > >>>> of > >>>>>> course Struts 2 needs mediating code to support it, but how coupled > >> is > >>>> it > >>>>>> really? > >>>>>> > >>>>>> Paul > >>>>>> > >>>>>> > >>>>>> On Wed, Sep 4, 2013 at 8:04 AM, Christian Grobmeier < > >>>> grobme...@gmail.com > >>>>>>> wrote: > >>>>>>> Folks, > >>>>>>> > >>>>>>> when researching on OGNL i found this link: > >>>>>>> > >> https://cwiki.apache.org/confluence/display/S2WIKI/OGNL+replacement > >>>>>>> In 2008 Brian mentioned "Security risks keep appearing" along with > >>> OGNL > >>>>>>> and collected the places where we use OGNL. Given the recent > >> events I > >>>>>>> thought it might be good to bring this up again. Please also note, > >> I > >>>>>>> have helped with OGNLs incubation and I am also touchign it over in > >>>>>>> Commons land. My impression is OGNL is not easy to understand and > >>> there > >>>>>>> is not really much interest from other people to develop on it. > >>>>>>> > >>>>>>> Looking at this list I feel OGNL is pretty much tied to Struts. On > >>> the > >>>>>>> other hand we could start to slowly decouple the two. Not sure what > >>> we > >>>>>>> should use otherwise. > >>>>>>> > >>>>>>> Any feelings on that? > >>>>>>> > >>>>>>> > >> --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > >>>>>>> For additional commands, e-mail: dev-h...@struts.apache.org > >>>>>>> > >>>>>>> > >>>>>> -- > >>>>>> Cheers, > >>>>>> Paul > >>>>>> > >>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > >>>> For additional commands, e-mail: dev-h...@struts.apache.org > >>>> > >>>> > >>> > >>> -- > >>> Cheers, > >>> Paul > >>> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
