Item1640: CommentPlugin writes "%" as html-code, which prevents the use of Macros

Priority: CurrentState: AppliesTo: Component: WaitingFor:
Normal Closed Extension CommentPlugin Main.KennethLavrsen

Description

Entering a Macro like IDEA! 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 wink

-- 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

ItemTemplate edit

Summary CommentPlugin writes "%" as html-code, which prevents the use of Macros
ReportedBy PhilippLeufke
Codebase
SVN Range Foswiki-1.0.0, Thu, 08 Jan 2009, build 1878
AppliesTo Extension
Component CommentPlugin
Priority Normal
CurrentState Closed
WaitingFor KennethLavrsen
Checkins Foswikirev:4026 Foswikirev:4027 Foswikirev:4028
TargetRelease patch
ReleasedIn 1.0.6
Topic revision: r16 - 08 Sep 2009, PhilippLeufke
 
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons License