Item12767: TopicInteractionPlugin allows WikiGuest to upload attachments and insert link to topic even if attach and edit are in {AuthScripts} setting

A user pointed out that he could attach a file to a topic and insert link into topic when not logged in. The uploaded file is attributed to WikiGuest. I investigated and confirmed this to be the case. Although NatSkin hides most topic actions if user is not authenticated, if a topic already has an attachment, TopicInteractionPlugin displays the attachment list along with an attach button which is fully functional.

To make clear the context, {AuthScripts} includes attach and edit but not rest (as suggested in Support.Question1368 ). If I enter the url for attach, authentication is triggered. Apparently TopicInteractionPlugin by-passes this in the way it uploads files.

As currently designed, this presents a potential security hole.

-- LynnwoodBrown - 05 Mar 2014

I can't reproduce this error. Please describe how you triggered any load plus insert link as WikiGuest, given the page is write restricted using Foswiki ACLs.

The way I tried the server returned a proper Access Denied Json RPC reply. Any such operation is properly guarded by checkAccess in the code. There is no way that this can be bypassed.

-- MichaelDaum - 06 Mar 2014

Ok, i'll dig deeper to see if i can find other factors. Let me check a couple of factors:

• Should the attachments list and the "Attach files" and "Options" buttons be visible to WikiGuest?
• Would having attach and edit in {AuthScripts} be sufficient or would further restriction (such as DENYWEBCHANGE) be needed on web level?

-- LynnwoodBrown - 06 Mar 2014

Yes, these things still make sense for guests, e.g. to query and download attachments. "Attach files" isn't visible for guests, nor the dialog behind the attach entry point. Any further action to manipulate the topic is guarded further down in the code. That's why protecting all of the rest entry point doesn't make sense. In other words: make sure your wiki is properly configured specifying ACLs. Otherwiselugins don't have a base to decide on access. I think that's not the case on the installation under consideration.

Baseline: fix your ACLs

-- MichaelDaum - 06 Mar 2014

I think the ACL's are correct on the site. If I manually enter the attach url, the authentication gets triggered. Following up on my second question, I tested and confirmed that if I explicitly set DENYWEBCHANGE to WikiGuest in WebPreferences, then it does work as I you say and as I'd expect. However, this is the only case I've seen where this is needed to deny WikiGuest edit/attach rights (i.e. having those scripts in {AuthScripts} has been sufficient). Being as there is currently no way to set DENYWEBCHANGE site-wide (e.g. it must be added to each web individually), this is too bad.

So if i'm understanding the situation correctly, since the plugin uses the rest call to upload the attachment (and edit the topic), it by-passes the {AuthScripts} restriction on attach and edit. Is that right?

-- LynnwoodBrown - 06 Mar 2014

No, that's not right. attach and edit are listed in {AuthScripts} so that they trigger the authentication process when called.

When it does so it says zero about the correctness of your ACLs being set in WebPreferences. So calling an attach url will (a) first force an authentication process and then (b) check access rights.

Authentication is forced by {AuthScripts} based on the entry point being listed. It does not expcess any access rights at all. These two things are different: authentication != access rights

TopicInteractionPlugin does not force authentication but does protect the wiki as other plugins do as well using ACLs. However if no ACLs have been expressed access is granted by default.

The issue is more - as you correctly discovered - that you have to make sure WikiGuest is denied access in any web by default ... which of course is what you always want anyway.

Two things we could action upon:

1. deliver Foswiki configured with proper ACLs denying WikiGuest in any web, i.e. the template _default webs
2. feature request: add global ACLs being set in SitePreferences.

In any case this has nothing to do with TopicInteractionPlugin itself.

-- MichaelDaum - 06 Mar 2014

I understand the distinction between authentication and access rights but in practice triggering for authentication has prevented access by WikiGuest. I can't think of any other place where this has not been the case. None the less, I get what you're saying and will proceed with adding explicit ACLs denying WikiGuest in each web. Of the two possible actions you mention, I would support the second as it would be easier to maintain.

-- LynnwoodBrown - 06 Mar 2014

Commenting is disabled while not logged in