end user editable templates, is it safe?

[S Ahmed]

I am hoping to use mustachejava like liquid:  http://liquidmarkup.org/

Seeing as mustache isn't really built with this use case in mind, what steps should I be taking to ensure the library is safe for end user modifications on a production server?

Seeing as mutache only renders whatever it is passed (objects, collections), it seems very safe to be on the surface?

I'm only asking what things can be done to make it equally as "safe" as liquid.

[Sam]

It hasn't been designed to be safe, so I won't make any claims about
it. Your biggest defense would be to create your own ObjectHandler
that overrides checkMethod and checkField to ensure that the template
isn't accessing anything you don't want it to access. All accesses go
through that class so I think it should be possible to lock it down.

Sam

[S Ahmed]

Tumblr has its own custom templating language that is end user safe, was hoping your mustache implementation could be used for a similar purpose.

Since the code injects whatever objects/fields will be available for parsing, to me it seems like it is very safe.

All you do (at a high level) is you parse for specific markers, then perform a lookup on the fields passed into mustache which are either variables or objects, and if they are objects you enumerate the objects properties and perform replacements.

I don't see how in could not be safe?  (The end user won't be writing the code that actually passes in the objects to mustache, just editing the template markup like one would with when creating a custom tumblr theme).

[Pohl Longsine]

I think your idea is interesting, and I believe it is safe enough to warrant giving the idea a shot.  

If you were to write your backing objects carelessly, I suppose you could make it possible for a user to create a template that repeatedly invokes a lot of expensive methods against your back-end, as a kind of Denial-of-Service attack.  

But if you think through the costs carefully so that any template the user writes can only result in reading fields from objects in memory (as opposed to blocking calls against a database) then you should be able to eliminate that possibility.

There would be some tradeoffs for doing that, because you would want to put anything the user might ask for in memory ahead-of-time, so that no matter what they write they would always be pulling from the pre-warmed cache.  This might mean that you would be pulling a lot of things into memory even when the user didn't need much of it.   

Depending on the nature of your application, that may or may not be a big deal.

[S Ahmed]

Good points and I was thinking of those casts already.

I was thinking of creating safe wrappers of my objects that would map whatever fields I want to expose, so before putting them in the HashMap that I was to mustache, I would wrap them in these safe-to-expose properties that would map the fields I want to expose.

OR

I could maybe add annotations on the properties that I want to expose (whitelist), so something like:

public class User {

   @MustacheWhitelist

   private String username;

   private String password;

}

Also, if I have to push to many things to the view, I could always run a regex on the template and build list of items that user has asked for, and only push those things down to the view.

[Sam]

The annotation idea along with your own ObjectHandler should be very
safe. If you cache the results of backend calls per request you can
probably avoid and sort of denial of service type attacks.

Sam

On May 12, 1:26 pm, S Ahmed <sahmed1...@gmail.com> wrote:
> Good points and I was thinking of those casts already.
>
> I was thinking of creating safe wrappers of my objects that would map
> whatever fields I want to expose, so before putting them in the HashMap
> that I was to mustache, I would wrap them in these safe-to-expose
> properties that would map the fields I want to expose.
>
> OR
>
> I could maybe add annotations on the properties that I want to expose
> (whitelist), so something like:
>
> public class User {
>    @MustacheWhitelist
>    private String username;
>    private String password;
>
> }
>
> Also, if I have to push to many things to the view, I could always run a
> regex on the template and build list of items that user has asked for, and
> only push those things down to the view.
>

[S Ahmed]

Also when a user saves a template, I could not mark it as approved until I execute the template with sample data.

I could execute it using a seperate thread that timesout after x seconds, so I can get an idea if there is any recursive/endless looping etc.