security1Add my vote for this tag create new tag
, view all tags


From the installation manual you could easily get the impression that enabling read access restriction would protect all content on a web site. This assumption is wrong. As illustrated by the example included below, unauthorized access to a protected topic is denied while download of the topic's attachments is unrestricted and open for everybody.

Access restriction for webs and topics rely on variables set in topics within TWiki. Therefore the same mechanism must be used to perform checks on attachments before they are retrieved. Storing attachments in a publicly readable directory like pub makes them readable by everybody that either guesses their location or find a URL in a browser history or even references in an email or on a web page.

There a script in bin/ called viewfile that seem to be abandoned. Perhaps we can bring it back to life for sites that require protected attachments? Of course I understand that it's umpteen times faster to just let the webserver serve the attached files directly from disk instead of squeezing them through a script, but if security isn't there I can't use that speed increase for anything useful anyway.

### Accessing a topic with read access restrictions enabled
bash-2.05a$ wget http://lindmark.net/cgi-bin/view/Private/TestPage
--15:04:01--  http://lindmark.net/cgi-bin/view/Private/TestPage
           => `TestPage'
Resolving webcache.east.sun.com... done.
Connecting to webcache.east.sun.com[]:8080... connected.
Proxy request sent, awaiting response... 302 Moved
Location: http://lindmark.net/cgi-bin/viewauth/Private/TestPage [following]
--15:04:02--  http://lindmark.net/cgi-bin/viewauth/Private/TestPage
           => `TestPage'
Connecting to webcache.east.sun.com[]:8080... connected.
Proxy request sent, awaiting response... 401 Authorization Required
Authorization failed.

### Accessing an attachment to the same topic
bash-2.05a$ wget http://lindmark.net/pub/Private/TestPage/analys.gif
--15:03:40--  http://lindmark.net/pub/Private/TestPage/analys.gif
           => `analys.gif.2'
Resolving webcache.east.sun.com... done.
Connecting to webcache.east.sun.com[]:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 4,533 [image/gif]

100%[====================================>] 4,533         31.85K/s    ETA 00:00

15:03:40 (31.85 KB/s) - `analys.gif.2' saved [4533/4533]

  • TWiki version: 20021211alpha
  • Perl version: 5.6.1
  • Web server & version: 1.3.27
  • Server OS: Linux
  • Web browser & version: Mozilla 1.2 and wget
  • Client OS: OS X 10.2.2

-- StefanLindmark - 16 Dec 2002


I have just run across this issue - it was on my to-do list, but now that my twiki users have started attaching spreadsheets and diagrams with sensitive information, it has become more important.

It is not just an issue of TWiki's access control - as reported elsewhere, I don't trust that, and rely on setgid scripts, i.e. UNIX security, for the more sensitive stuff. One significantr problem is that the pub/ directories containing the attachments must be readable to the web server httpd, which means that, on many systems, they are effectively readable to the world.

-- AndyGlew - 20 May 2003

I have also run into this issue. We are using TWiki as a client collaboration site (which may or may not be entirely appropriate). We have managed to secure the clients' webs from each other using a combination of users/groups and authentication. However, this doesn't, as mentioned above, prevent anyone from viewing FileAttachments if they know the direct URL.

Is there a workaround/solution to this? I haven't been able to find one. Also, is this issue being worked on in continuing development? If it isn't I'd be happy to take a look at it. I'm both new to TWiki and new to Perl, but I'd be happy to contribute any solution I could come up with.

-- KyleTippetts - 11 Nov 2003

I've found a manual solution to this problem if you're using Apache. It's a manual solution in the sense that you'd have to have root access to the web server twiki was running on to make the necessary changes. However, it works for our heightened security needs, so I'm posting it here.

The basic premise is to secure the individual directories below the pub directory so that only authorized users (members of a group) can access the files contained therein. To do this:

  • Create a group file that lists all of your twiki groups and the groups' associated users.
  • Create an .htaccess file for each web that you want to secure and place the file in pub/[webname].
  • Modify httpd.conf so that for the pub directory, AllowOverride All is set.

This solution assumes that you are using password authentication and access control as discussed in TWikiAccessControl.

Here are the details for each bullet point:

Create the group file

  1. Create a file called .htgroups (the name really doesn't matter) and put it in the data directory.
  2. In the file, enter all of the group names that you want to use for securing the pub directories, along with their
associated users: in this format:

[GroupName]: user1 user2 user3 ...

Here is an example:

         DevGroup: BillFreely EugeneKwan AntonyMartinez AnneFitzgerald
         MarketingGroup: LulaTong GeraldWeasley
         TestingGroup: SteveBrale SueBraxton MariaFerron

Create the .htaccess file

  1. Create a file called .htaccess in the pub/[webname] directory.
  2. Enter the following into the file, replacing paths and filenames to match your installation:

       AuthUserFile /usr/www/apache2/htdocs/twiki/data/.htpasswd
       AuthName 'TWikiSite'
       AuthType Basic 
       AuthGroupFile /usr/www/apache2/htdocs/twiki/data/.htgroups
       ErrorDocument 401 /twiki/bin/oops/TWiki/TWikiRegistration?template=oopsauth

       Require group DevGroup

Copy this file into every pub/[webname] directoy which you want to secure, changing the Require group line to contain the group that should have access.

Modify httd.conf

Modify the <Directory "/usr/www/apache2/htdocs/twiki/pub">'s AllowOverride setting so that it says

   AllowOverride All

This tells Apache to use .htaccess files if it finds them in pub and any of it's subdirectories.

NOTE: I'm currently trying to develop an automated way to handle all of this. That is, a way to sync up TWiki group topic files with their corresponding .htaccess files in pub/[webname]. More to come.

-- KyleTippetts - 17 Nov 2003

One modification to the above procedure is to use the same value for AuthName for the .htaccess file in the pub directory as well as the .htaccess file in the cgi-bin directory protecting the twiki executables.

On most browsers, the user/password pair will automatically be sent for the pub directory since the protected "space" has the same name. This means that the user will only need to login once. If you want the user to login each time, make sure the AuthName values are not the same.

-- SamPai - 23 Jan 2004

Does this still represent the current status? The lack of attachment protection seems like a definite shortcoming. At least from the concerned-but-clueless user perspective :-/

-- HenningRuch - 25 Nov 2004

Yes, I believe it does. I do think someone was working on this, though... sorry for being vague.

-- RichardDonkin - 26 Nov 2004

Thanks! At least I know I don't need to hunt for the perfect final solution now.

Let me try to sum up the current status:

"Kyle's solution establishes attachment read protection, but relies on manual administration of user lists and group lists that are not integrated in the standard TWiki user management tools."

If that's correct, I think I'm still content with TWiki's access control. (Access control is an important criterium for selecting a wiki engine for our corporate intranet.)

-- HenningRuch - 26 Nov 2004

The documentation gives the idea that attachments have the same access restrictions as (their) topics. This at least should be changed as soon as possible. I, for one, wonder if there are more security issues this big I did not see yet...

I think there should be option to disable directly accessable attachments and using the deprecated viewfile again (during installation for example). Security is more important than speed in corporate LAN's.

In the temporary solution provided by KyleTippetts: POSSIBLE SECURITY ISSUE: What happens when people upload .htaccess files? Does it override the .htaccess file in the parent directory?

  • This is protected with TWiki.cfg's $uploadFilter set to "^(\.htaccess|.*\.(?:php[0-9s]?|phtm[l]?|pl|py|cgi))\$" -- PTh

-- MichielVisser - 16 Feb 2005

In line with SamPai about ease of log-in, this is the .htaccess file I placed in /twiki/pub to close off the attachment link to registered users. It seems like a simple one-time fix solution, so I am a little worried that their is a flaw that makes the AuthGroupFile and manual .htgroup editing necessary.

AuthUserFile your_path/twiki/data/.htpasswd
AuthName 'Enter your WikiName: (First name and last name, no space, no dots, capitalized, e.g. JohnSmith). Cancel to register if you do not have one.'
AuthType Basic
ErrorDocument 401 /twiki/bin/oops/TWiki/TWikiRegistration?template=oopsauth

require valid-user

-- MattRoelle - 04 Aug 2005

The fix/work around that MattRoelle provided works great for restricting the pub directory to only authenticated users.

FYI: You will also need to change the AllowOverride setting on the pub directory in your httpd.conf from None to AuthConfig.

-- DavidMMiller - 23 July 2007

  1. The above solutions fail as soon as someone adds a new web
  2. SecuringAttachments has the promise of a solution but as of a year later Sophan has not followed up on it.

-- MartinCleaver - 02 Nov 2007

A solution is described in TWikiAccessControl#Controlling_access_to_Attachment, albeit slow for embedded pictures.

-- PeterThoeny - 02 Nov 2007

Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r17 - 2007-11-02 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.