You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@freemarker.apache.org by Alon Ziv <no...@google.com.INVALID> on 2023/01/13 16:39:50 UTC
Opinion requested: security settings for not-fully-trusted templates
We have internal code @google that executes templates that aren't fully
trusted. Currently we use Java introspection on the Template object (using
internal class names 😕) to verify such templates do not use constructs we
deem "unsafe", such as disabling auto-escaping via "?noEsc" or
<#noautoesc>, as well as the "?eval" and "?interpret" built-ins.
We are considering upstreaming these capabilities; some combination of:
- Provide a formal API for walking the template AST (rather than the
existing test-only ASTParser)
- Create a Configuration setting for "forced escaping" - which will
disable "?noEsc" and <#noautoesc> for the affected template at parse time
- Adding Configuration settings for "disable Interpret" and "disable
Eval" (likely a bit flag so it's potentially extensible easily)
Will such work be welcome by the project?
Re: Opinion requested: security settings for not-fully-trusted templates
Posted by Daniel Dekany <da...@gmail.com>.
Above is a duplicate because of moderation... sorry.
On Sat, Jan 14, 2023 at 10:56 AM Alon Ziv <no...@google.com.invalid>
wrote:
> We have internal code @google that executes templates that aren't fully
> trusted. Currently we use Java introspection on the Template object (using
> internal class names 😕) to verify such templates do not use constructs we
> deem "unsafe", such as disabling auto-escaping via "?noEsc" or
> <#noautoesc>, as well as the "?eval" and "?interpret" built-ins.
>
> We are considering upstreaming these capabilities; some combination of:
>
> - Provide a formal API for walking the template AST (rather than the
> existing test-only ASTParser)
> - Create a Configuration setting for "forced escaping" - which will
> disable "?noEsc" and <#noautoesc> for the affected template at parse time
> - Adding Configuration settings for "disable Interpret" and "disable
> Eval" (likely a bit flag so it's potentially extensible easily)
>
>
> Will such work be welcome by the project?
>
--
Best regards,
Daniel Dekany