Priority: Normal
Current State: Closed
Released In: 1.0.6
Target Release: patch
Description
Entering a Macro like
doesn't work, as the "%" gets translated into its html-code
%
Discussion
Did some debugging. Disabled all other plugins: Still the same behaviour.
--
PhilippLeufke - 24 May 2009
Yes, that was a deliberate design decision - or more truthfully, a bug fix after the first release. The problem is that if you allow COMMENT to be used to inject other macros, you end up with an open invitation to phishers, spammers, and other such unclean filth.
--
CrawfordCurrie - 24 May 2009
Well, I don't get what's the difference between adding content via an editor or by posting a comment via the plugin. Why is there a higher security risk for the latter way? Maybe you can post a link where I can find the discussion?!
Anyway: since this our wiki is firewalled and only accessible from the intranet, I'd rather have at least an option to enable entering makros using the
CommentPlugin. And I guess, I may not be the only one.
It's just a question of usability...
(Setting back to "feedback required" as I'm really curious about the security details...)
--
PhilippLeufke - 25 May 2009
Sorry Philipp, this was all a very long time ago. There
may be a written history, but if so it'll be on twiki.org. Because it was a security issue, it may not even have made it there. I just haven't got time to research it right now - and because of that, you are justified in asking for it to be configurable (or much better, coding it yourself)
I changed this report to "Enhancement" and "Confirmed"
--
CrawfordCurrie - 26 May 2009
I think the issue is more severe than just to avoid spammers. This topic
http://twiki.org/cgi-bin/view/Support/CommentPluginExpandsVariables is a hint of it.
I feel a nest of hornets in my trousers and they are about to wake up. This would need a very careful design process before attempted with security focus.
I will see if I can dig more history out. But do not expect this to be changed in a near future as we have development focus elsewhere at the moment.
--
KennethLavrsen - 26 May 2009
Thanks for the replies! But can somebody tell me why expansion of variable is a security risk for the
CommentPlugin and
not when a topic is edited by hand (using text or WYSIWYG editor)? Where is the difference?
--
PhilippLeufke - 26 May 2009
I have been digging into this.
I wanted to know what happened and I now know the story.
There are actually two security issues.
The first was a temporary one we had for a short while back in 2006 where a development version by error expanded macros instead of just saving them. This was fixed and the behavior reverted back to saving the macros as macros
Then last year in October/November we had a report of a XSS (cross site scripting) which resulted in TWiki having to issue a CVE report. Foswiki at that time had not released the first version yet and did a very thorough security update. The attack vectors were multiple - much more than TWiki fixed but the one that comes to play here is URLPARAM. Any topic with URLPARAM could be used to inject javascript via XSS attacks. So we chose to change URLPARAM by introducing a new encoding scheme called "safe" and making this the default. It is however still possible to enable the unsafe use by using URLPARAM with encode="off". I do not recommend this though but if it is important to you for specific
CommentPlugin templates then you can use it those specific places. It is only the comment template topic that becomes the attack vector. If you define a user template for
CommentPlugin an attacker from the outside needs to 1) know the topic name on which you have the unsafe URLPARAM and 2) know the variable name you chose and 3) find something useful to inject on this comment template topic. I would not worry about that. Simply add an
INCLUDE to include an additional comment template topic in
CommentPluginTemplate
and add your own comment types there.
But we will not change our distributed Foswiki to include unsafe use of URLPARAM. I will consider if
CommentPlugin needs a little note about URLPARAM and the encode="safe" default. Assigning it to myself to do docu update.
For you Philipp you should have the info you need to adjust the URLPARAM in the
CommentPlugin templates so I hope we have made yet another happy customer
--
KennethLavrsen - 26 May 2009
Wait a minute. It is a long time since we put all the
CommentPluginTemplate
templates into verbatim tags. I actually think it is safe to add the encode="off" or maybe just encode="quotes" to the templates.
I cannot see any attack vector being opened by doing that. We test my assumption with some of the other developers. If this is OK then I say we change the plugin to allow more free use of Macros per default.
--
KennethLavrsen - 26 May 2009
I have analysed the problem and as long as we use URLPARAM in the OUTPUT part of
the
CommentPlugin templates and keep the settings inside verbatim tags we do not
expose any XSS attack. So we can give the users back the ability to use Foswiki
Macros in comment input fields.
With this I also merge over some code changes Crawford had done in trunk.
Note that except for the release version all changes in the .pm files are unrelated
to the bug fix, which is why I dare checking in perltidy stuff with a bug fix.
CommentPlugin is now again same in trunk and Release branch
--
KennethLavrsen - 04 Jun 2009
Reopening this as the problem still is present in our installation (latest debian packages)
and also in the foswiki.org version.
--
PhilippLeufke - 07 Sep 2009
If the bug is present in debian then it is because the debian package is not up to date. That is a new bug in itself and should be raised as a new bug.
The version you download from foswiki.org has this fixed also.
Did you mean the version running on foswiki.org? If so we could reopen 1000 bugs or more because this site is still not upgraded since 1.0.0
--
KennethLavrsen - 07 Sep 2009
It was my fault. It
is fixed, but our
UserCommentsTemplate was overwriting it. Mea culpa.
Sorry!
--
PhilippLeufke - 08 Sep 2009