Class SecureASTCustomizer

java.lang.Object
org.codehaus.groovy.control.customizers.CompilationCustomizer
org.codehaus.groovy.control.customizers.SecureASTCustomizer
All Implemented Interfaces:
CompilationUnit.IPrimaryClassNodeOperation

public class SecureASTCustomizer extends CompilationCustomizer
This customizer allows securing source code by controlling what code constructs are permitted. This is typically done when using Groovy for its scripting or domain specific language (DSL) features. For example, if you only want to allow arithmetic operations in a groovy shell, you can configure this customizer to restrict package imports, method calls and so on.

Most of the security customization options found in this class work with either allowed or disallowed lists. This means that, for a single option, you can set an allowed list OR a disallowed list, but not both. You can mix allowed/disallowed strategies for different options. For example, you can have an allowed import list and a disallowed tokens list.

The recommended way of securing shells is to use allowed lists because it is guaranteed that future features of the Groovy language won't be accidentally allowed unless explicitly added to the allowed list. Using disallowed lists, you can limit the features of the language constructs supported by your shell by opting out, but new language features are then implicitly also available and this may not be desirable. The implication is that you might need to update your configuration with each new release.

If neither an allowed list nor a disallowed list is set, then everything is permitted.

Combinations of import and star import constraints are authorized as long as you use the same type of list for both. For example, you may use an import allowed list and a star import allowed list together, but you cannot use an import allowed list with a star import disallowed list. Static imports are handled separately, meaning that disallowing an import does not prevent from allowing a static import.

Eventually, if the features provided here are not sufficient, you may implement custom AST filtering handlers, either implementing the SecureASTCustomizer.StatementChecker interface or SecureASTCustomizer.ExpressionChecker interface then register your handlers thanks to the addExpressionCheckers(ExpressionChecker...) and addStatementCheckers(StatementChecker...) methods.

Here is an example of usage. We will create a groovy classloader which only supports arithmetic operations and imports the java.lang.Math classes by default.

 final ImportCustomizer imports = new ImportCustomizer().addStaticStars('java.lang.Math') // add static import of java.lang.Math
 final SecureASTCustomizer secure = new SecureASTCustomizer()
 secure.with {
     closuresAllowed = false
     methodDefinitionAllowed = false

     allowedImports = []
     allowedStaticImports = []
     allowedStaticStarImports = ['java.lang.Math'] // only java.lang.Math is allowed

     allowedTokens = [
             PLUS,
             MINUS,
             MULTIPLY,
             DIVIDE,
             MOD,
             POWER,
             PLUS_PLUS,
             MINUS_MINUS,
             COMPARE_EQUAL,
             COMPARE_NOT_EQUAL,
             COMPARE_LESS_THAN,
             COMPARE_LESS_THAN_EQUAL,
             COMPARE_GREATER_THAN,
             COMPARE_GREATER_THAN_EQUAL,
     ].asImmutable()

     allowedConstantTypesClasses = [
             Integer,
             Float,
             Long,
             Double,
             BigDecimal,
             Integer.TYPE,
             Long.TYPE,
             Float.TYPE,
             Double.TYPE
     ].asImmutable()

     allowedReceiversClasses = [
             Math,
             Integer,
             Float,
             Double,
             Long,
             BigDecimal
     ].asImmutable()
 }
 CompilerConfiguration config = new CompilerConfiguration()
 config.addCompilationCustomizers(imports, secure)
 GroovyClassLoader loader = new GroovyClassLoader(this.class.classLoader, config)
  

Note: SecureASTCustomizer allows you to lock down the grammar of scripts but by itself isn't intended to be the complete solution of all security issues when running scripts on the JVM. You might also want to consider setting the groovy.grape.enable System property to false, augmenting use of the customizer with additional techniques, and following standard security principles for JVM applications.

For more information, please read:

  • Improved sandboxing of Groovy scripts
  • Oracle's Secure Coding Guidelines
  • 10 Java security best practices
  • Thirteen rules for developing secure Java applications
  • 12 Java Security Best Practices
  • Since:
    1.8.0