Let's restrict this discussion to the case of 'authenticated and authorised users' of an 'enterprise platform'.
When we talk about 'unsafe input' vs 'safe input', I'm still confused about what this actually entails. Let's assume we want those users to enter a (JEXL) expression to express their functional need (think of an enterprise spreadsheet of some kind with some built-in constraints). Is this considered an 'unsafe input' by essence ? If so, we need to 'sanitise' it to ensure it is 'harmless' - that being a broad definition. So, what does it mean to 'sanitise' such an input ? You can not do it by an external mean (external to JEXL); well, you could, but then there is almost no point in using JEXL then since you'd already done most of the hardwork of syntactic and semantic checks. Assuming then that the only practical way to control what a script can do is through JEXL itself; splitting the platform scripting feature using different classes/modules/jars still requires configuring these environments properly. And we cannot do this through JEXL jars since we can't know those environment constraints before hand. My proposal of enforcing a default configuration with a very narrow permeability is meant to ensure the platform developers at least realise they have to think about what they expose to whom. Isn't this the resolution strategy we used for the latest log4j2 and text CVEs - Avoid defauit configurations that are too permissive ? > > The primary driver for my thinking is observation of projects that have > tried to separate safe and unsafe functions via configuration and the > steady stream CVEs raised against those projects as security researchers > find ways to bypass the filtering. If there is a requirement to support > unsafe input then I think a stronger separation is required. > > One solution would be different scripting engines for the two use cases > (trusted and untrusted) but that is likely to result in duplicate code > of some form - something else that I don't like. > > Not knowing JEXL at all, would it be possible to have a "safe" JAR that > only provided features for untrusted input and an "extension" JAR you > could add to enable all the "dangerous" features for use with trusted input? > > Mark > > > > > >> > >> This sort of functionality is only required if an application is passing > >> untrusted / unsanitised input to JEXL. That seems an extremely dangerous > >> thing to do to me. Do we have any indications that any real world users > >> are doing this? > >> > >> If the project starts down the road of being "secure by default for > >> untrusted input" then rather than the project avoiding future CVEs, it > >> opens itself up to a long stream of future CVEs as researchers find ways > >> to bypass the restrictions put in place. > >> > >> My recommended approach for projects like JEXL would to be clearly > >> document that all input is expected to be trusted and then reject any > >> vulnerability reports based on processing untrused input. > >> > >> If there are users that need to process untrusted input then I'd suggest > >> starting with asking how they are currently validating / sanitising that > >> input. > >> > >> Mark > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
