Is your feature request related to a problem? Please describe.
There a few Javascript sensitive eval() statements in the components to implement
dynamic configuration of features, e.g. hidden/required/read-only fields, display of buttons...
This usage has been already minimised and no implicit execution is possible: administrators need
to explicitly activate dynamic condition evaluation via a dedicated boolean flag in the configuration.
At last, most of the time, conditions rely on boolean, picklist, numeric or lookup fields, leaving less options
open to inject malicious code than text or richtext fields (especially those modifiable by users).
Describe the solution you'd like
N/A
Describe alternatives you've considered
One option would be to implement some regex matching rules to prevent some usual dangerous
keywords or syntax in the conditions being evaluated: e.g. check that there are no “;”, “{”, “window”
or “document” keywords, see safe-eval() for node.js.
Is your feature request related to a problem? Please describe. There a few Javascript sensitive
eval()statements in the components to implement dynamic configuration of features, e.g. hidden/required/read-only fields, display of buttons... This usage has been already minimised and no implicit execution is possible: administrators need to explicitly activate dynamic condition evaluation via a dedicated boolean flag in the configuration. At last, most of the time, conditions rely on boolean, picklist, numeric or lookup fields, leaving less options open to inject malicious code than text or richtext fields (especially those modifiable by users).Describe the solution you'd like N/A
Describe alternatives you've considered One option would be to implement some regex matching rules to prevent some usual dangerous keywords or syntax in the conditions being evaluated: e.g. check that there are no “;”, “{”, “window” or “document” keywords, see safe-eval() for node.js.
Additional context N/A