I looked over that article as well... like Siegfried says in spite of the title
of the article it started with a privilege escalation attack that was
independent of FreeMarker to get access to edit templates. Because of that it
also was node an injection attack, those are totally different
Hi Daniel,
I guess I need to re-read the FreeMarker documentation and ticket - having said
that
* The problem described in the article was less about arbitrary people but
someone who hacked through other security issues to become administrator with
temple editing rights
* The people having
Hi Daniel
Some thoughts along the line
* I found having "documents[]" and "Documents" a bit confusing
* I want to minimise the number of top-level objects in the data model
* Documents gives you array access and wildcard search
* The documents have exactly the same order as specified on the
Looks great from the change log!
But, one thing I find to be odd is "Do not use documents[0] as top-level
variable - use Documents.get(0) instead ". I have already found loading
data a bit too hard to read (not utilizing what FreeMarker can do), but I
didn't come up with a concrete proposal for
Hi,
In short, allowing untrusted users to edit templates is not supported. But,
since people do it anyway, 2.3.30 will make an effort to allow doing that
with taking far less risk than what people take now. The MemberAccessPolicy
feature committed in recent days is the start of that. Actually,
Hi folks,
During my last presentation I was asked about how secure Apache Freemarker is
in the context of user editing their templates - well, hard to say without
knowing the application.
But I came across an interesting article (see
Hi folks,
Following the discussion (see below) I released
https://github.com/sgoeschl/freemarker-cli/releases/tag/v2.0.0-BETA-5
* The available tools are loaded from "freemarker-cli.properties" and support
user-supplied tools
* Apache POI / Excel integration supports getting to raw tables
