Our level of security is precisely as you guessed: we have well-meaning but ill-informed template authors, who sometimes unwittingly enable XSS (especially as our org is large, and the data providers and template authors are often from different teams). The pull-request you had already merged into 2.3.22 (https://github.com/apache/freemarker/pull/83) is already part of our solution: we're basically preventing the templates from ever turning off auto-escaping, and instead we provide data-driven mechanisms to enable similar functionality in a way fully controlled by our Java code.
We're perfectly OK with upstreaming only the acceptable parts of our solution - e.g., per-template flags to control "?noEsc", "?eval", and "?interpret". (We'll still need to use our hackish AST-walking solutions to cover additional edge cases, but anything we do with upstream is one less hack we need to maintain.) On Sat, Jan 14, 2023 at 9:31 AM Daniel Dekany <daniel.dek...@gmail.com> wrote: > Sounds doable at first glance. Some of them at least, like disabling > certain built-ins. It's certainly a good idea to discuss how you intend to > do things early, to avoid back-and-forths later. > > Can you tell more about the kind of template security you are looking for? > I assume you have seen the related FAQ entry ( > > https://freemarker.apache.org/docs/app_faq.html#faq_template_uploading_security > ), > but it seems you want to do some more here. Like dodging the mistakes of > well meaning template authors , which then could allow XSS attacks by > those who can only provide data to the templates? > > Exposing AST has some dilemmas for non-technical reasons. Generally, the > main hurdle with FreeMarker 2 is that we have to keep backward > compatibility. While we don't have a pubLISHED AST API-s, part of it is > unfortunately still public. Also, after 20 years we can expect some user > code to even check non-public class names, etc. Like maybe you did too. > That's why the API was never cleaned up either. So, if you can have these > flags, do you still need to expose the AST? I would prefer to expose higher > level functionality to users instead. > > On Fri, Jan 13, 2023 at 7:39 PM Alon Ziv <nola...@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 >
smime.p7s
Description: S/MIME Cryptographic Signature
