Fair points, thank you. They seem to lead into the point of view that JEXL (or
any scripting solution?) should not expose any feature that could be considered
security-related avoiding the CVE potential turmoils alltogether. Trusted
sanitised input is expected and required so this is a moot discussion.
In the EPM field at least, there are real world users who would like to have
ways to express a computation, a formula, a label, - anything from a one line
expression, snippet to script -through the platform/application they use daily
- rather than depend and wait for IT/consultants/software-vendors to implement
it. I'm not saying it is reasonable or achievable but is desired. The latest
low-code hype is probably fuelled by the same functional needs.
Anyhow, it seems reasonable - at least useful - to help control the danger of
allowing 'scripting' in a platform. It seems we reduce little of that issue if
our stance on security is 'the only scripts you should run are scripts that are
trusted'. Even a 'trusted user' can have a nefarious intent...
A 'sanitised input' can only be enforced by configuring precisely the (JEXL)
engine (JexlPermissions, JexlFeatures, JexlOptions). Even if we rightfully
reject any CVE due to a poorly configured engine, we can probably avoid the
obvious ones in the first place.
Wether security should be addressed by some features seems to be the underlying
chasm... Interesting conundrum :-)
>
> 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
