Am Fr., 24. Jan. 2020 um 23:29 Uhr schrieb Daniel Dekany <
daniel.dek...@gmail.com>:
> Um... So what I said is that the @ thing is not part of a public API
> *currently*, but the other parts are. The main reason of that is that the
> "rules" (i.e., "whitelistPolicyIfAssignable" and
> "blacklistUnl
Um... So what I said is that the @ thing is not part of a public API
*currently*, but the other parts are. The main reason of that is that the
"rules" (i.e., "whitelistPolicyIfAssignable" and
"blacklistUnlistedMembers") are some ad hoc hacks to make a less unsafe but
still mostly backward compatibl
Am Mi., 22. Jan. 2020 um 21:51 Uhr schrieb Daniel Dekany <
daniel.dek...@gmail.com>:
> Off hand, I have no objections. Though I don't yet know exactly how you
> imagine it. MemberSelector.parse and MemberSelector.isIgnoredLine are
> public.
> The "@" syntax parsing is not public.
I see.
>
Off hand, I have no objections. Though I don't yet know exactly how you
imagine it. MemberSelector.parse and MemberSelector.isIgnoredLine are
public. The "@" syntax parsing is not public. Do
you intend to use that in your application?
On Wed, Jan 22, 2020 at 12:45 AM Christoph Rüger
wrote:
> D
Daniel, do you have any objections to refactoring the file-parsing-code in
DefaultMemberAccessPolicy to be reusable? e.g. to use it against an own
file which is structured like DefaultMemberAccessPolicy-rules? Even when
using WhitelistMemberAccessPolicy it would be great to maintain this in a
file
Am Do., 16. Jan. 2020 um 07:49 Uhr schrieb Daniel Dekany <
daniel.dek...@gmail.com>:
> Quick idea... What if you create a MemberAccessPolicy implementation that
> just delegates to the actual WhiltlistAccessPolicy, which is in an
> AtomicReference field. When something registers a new piece a whit
Quick idea... What if you create a MemberAccessPolicy implementation that
just delegates to the actual WhiltlistAccessPolicy, which is in an
AtomicReference field. When something registers a new piece a whitelist,
you fully recreate this embedded WhitelistAcessPolicy. I guess such even
would be rar
First of all, great stuff. Also thanks for
making BeansWrapper.invokeMethod(Object, Method, Object[]) protected, as
this helps us to monitor method invocations. As you write in a comment it
will be "significant work to put together" a whitelist, but this will help
to do so. Do you think it makes se
And updated it again... I hope I won't find any more things I missed to
address.
Anyway, I think we should start going for a release (in a month or
something), so, Christoph, any idea when can you say something about the
OSGi issues? I don't want to release something where that can't be solved.
O
I have also updated the default member access policy, so the tricks you
tried back then shouldn't work anymore, even if you don't use your own
member access policy. But, you still definitely should use your own policy,
if users aren't trusted.
The other API-s and Javadocs were evolved too a bit si
Am Mi., 1. Jan. 2020 um 22:12 Uhr schrieb Daniel Dekany <
daniel.dek...@gmail.com>:
> Guys,
>
> I have add MemberAccessPolicy to the API, which you can plug into a
> DefaultObjectWrapper (or to any BeansWrapper). I have also added
> WhitelistMemberAccessPolicy, to ease adding a restrictive policy.
Guys,
I have add MemberAccessPolicy to the API, which you can plug into a
DefaultObjectWrapper (or to any BeansWrapper). I have also added
WhitelistMemberAccessPolicy, to ease adding a restrictive policy. Please
take a look. 2.3.30-SNAPSHOT is in the Apache snapshot repo, as usual. You
can start o
HI Daniel,
Would it make sense to come up with a separate chapter for the existing
FreeMarker documentation to explain the things in detail?
Thanks in advance,
Siegfried Goeschl
PS: Last email for today - preparing Christmas dinner :-)
> On 24.12.2019, at 18:23, Daniel Dekany wrote:
>
> I
I responded to your mail that says "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". So I
thought that the premise there was that people who shouldn't be able to
edit templa
Hi Daniel,
Not sure about your line of thoughts :-)
My understanding
* There is a recipe out there how someone can access the file system and the
setup was not bad security-wise - only "?api" built-in was enabled
* I think the "?api.class.getResource" and "?api.class.getResourceAsStream" can
b
The blog entry might starts its case with a privilege escalation
independent of FreeMarker, but the question you got during your
presentation wasn't about that, I think. But more importantly, some real
world applications do allow editing templates for users who aren't
necessarily some kind of super
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 from
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 tha
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, you
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
https://ackcent.com/blog/in-depth-freemarker-template-inject
20 matches
Mail list logo
