Dear Yasser I perfectly understood that the proposed change is proactive and that there are no open known vulnerabilities. ;-)
Best regards Markus Am 16.09.19 um 15:42 schrieb Yasser Zamani: >> -----Original Message----- >> From: i...@flyingfischer.ch <i...@flyingfischer.ch> >> Sent: Monday, September 16, 2019 4:58 PM >> To: dev@struts.apache.org >> Subject: Re: Max length for OGNL expression >> >> Dear Yasser >> >> we definitively need an option to totally disable this "feature". It really >> depends >> on what kind of application you deploy. > Yes it's going to be user configurable and setting it to 0 would disable it :) > >> Logging a warning seems appropriate. But we should avoid logging a warning >> while the "feature" is disabled. > Yes of course, +1. > >> I also fear that this will lead to vulnerable applications, because the >> "default" >> settings are not vulnerable to a given attack and therefore the framework >> "needs >> no fixing". As I said before: the proposed fix is at the wrong place. I may >> be >> mistaken, but we should try to find solutions at the core of the problem. > (Sorry I forgot to mention earlier) Yes we have already fixed all known > vulnerabilities. This one is just a proactive try for possible unknown > expression injection vulnerabilities which are discovered by hacker sooner > than us. So this is going to make it harder to actually exploit such unknown > vulnerabilities. > > Kind Regards. > >> However, as long as we have an option to disable this, it should work out. >> >> Markus >> >> >> Am 16.09.19 um 14:09 schrieb Yasser Zamani: >>> Thanks Markus and Christoph! Please see inline and see if it satisfies those >> challenges. >>>> -----Original Message----- >>>> From: christoph.nenn...@bmw.de <christoph.nenn...@bmw.de> >>>> Sent: Monday, September 16, 2019 11:39 AM >>>> To: dev@struts.apache.org >>>> Subject: AW: Max length for OGNL expression >>>> >>>> I agree with this. Basically I like the idea to limit length of ognl >>>> and I think it would increase security. But IMHO it is likely to >>>> cause issues in applications and thus applications must be able to control >>>> it. >>> Yes. By "config element" I meant they will be able to override it or set it >>> to a >> very large number to disable it in their struts.xml. Please see also below. >>>> Regards, >>>> Christoph >>>> >>>> >>>>> Seems to me not to be the right place to correct any possible >>>>> problems, and far off any related root of a possible issue. >>>>> >>>>> The config would definitively need an option to be disabled totally. >>>>> I expect very unexpected and hard to trace side effects, depending >>>>> on the application in place. >>> Yes I have already thought that users might have long expressions e.g. <s:if >> test="<long expression>" but I think there exists an N such that no user has >> any >> expression longer than N. For example I guess N=200. Somebody might claim >> N=500 but at bottom we can discuss and find a default for N. >>> Furthermore we will log.warn() such unlikely expressions before >>> blocking them, so user will be able to find and amend them which makes >>> code more readable and maintainable -- obviously a raw expression >>> longer than 200 should be hard to maintain and read :) >>> >>> Best Regards. >>> >>>>> Markus >>>>> >>>>> Am 15.09.19 um 09:58 schrieb Yasser Zamani: >>>>>> Hi, >>>>>> >>>>>> I thought it might be nice to add a config element which confines >>>>>> the length of OGNL expression that Struts is going to evaluate. It >>>>>> is going to make hackers life harder :) >>>>>> >>>>>> How do you see it? >>>>>> >>>>>> Best. >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------- >>>>>> - >>>>>> - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For >>>>>> additional commands, e-mail: dev-h...@struts.apache.org >>>>>> >>>>> -------------------------------------------------------------------- >>>>> - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For >>>>> additional commands, e-mail: dev-h...@struts.apache.org >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For >>> additional commands, e-mail: dev-h...@struts.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional >> commands, e-mail: dev-h...@struts.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
