On 26/10/2022 08:58, Henri Biestro wrote:
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 :-)
Indeed.
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
