Securing File Attachments

	Content below is outdated. See official documentation at TWiki.TWikiAccessControl#ControllingAttachments

-- PeterThoeny - 2009-11-06

I've recently setup a secure Web on an existing TWiki server at work. Using the security settings gives me acceptable security (read and write protected) for topics, but not for attachments. If someone accidentally emails the URL for an attachment then anybody can read it.

I've made a few code changes to get round this, which I've outlined below. Is this something people would like to see in the core?

• I've altered viewfile so that it doesn't re-direct to pub
• I've added a permission check to viewfile, assumes you need view permission on a topic to be able to view an attachment
• I've used Apache mod_rewrite to change references to pub to use viewfile, with the exception of my images directory and the TWiki Web

-- JohnTalintyre - 08 Oct 2003

This is a welcome addition!

-- ArthurClemens - 08 Oct 2003

Sounds good.

-- MartinCleaver - 08 Oct 2003

This would also help with EncodeURLsWithUTF8, since it gives an opportunity to convert the URL encoding for attachment URLs. This should apply to all URLs of course - currently, attachment URLs in the end of topic table etc point directly to the pub hierarchy. As ViewfileCgiScript points out, viewfile is used when selecting earlier versions of attachments from the Actions page. Not everyone has access to mod_rewrite so TWiki should really download all attachments via viewfile without requiring this.

Use of redirect vs direct download should be tested, as I'm sure Apache will be more efficient for really large downloads. It may be worth making this configurable for sites where security is less important.

-- RichardDonkin - 09 Oct 2003

A collegue at work reckons is working on a Perl Apache module that can deal with this more efficiently. I add more soon.

-- JohnTalintyre - 09 Oct 2003

This is a good idea. Details need to be worked out:

• What happens with %ATTACHURL%/file.ext and %PUBURL%/%WEB%/Topic/file.ext constructs?
• Should inlined content like images be excluded from the viewfile script? If not, we will see a consiberable performance loss for composite pages.
• For a delayed authentication, do we need a viewfileauth symlink, like viewauth?
• Docs need to be done for URL rewrite so that admins of other web servers can configure the system. Any way without URL rewrite?

-- PeterThoeny - 10 Oct 2003

What about adding another directory, "private", i.e. %PRIVATEDIR% that should be put outside the web server root (like data/), and a new flag for attachement telling if the attachement should be private or not. The default could be a preference (most intranets would like private by default, most public sites public per default).
-- ColasNahaboo - 10 Oct 2003

Answering Peter's questions from above:

• What happens with %ATTACHURL%/file.ext and %PUBURL%/%WEB%/Topic/file.ext constructs?
  • Dealt with by the re-write
• Should inlined content like images be excluded from the viewfile script? If not, we will see a consiberable performance loss for composite pages.
  • As I said above, I left images and pub off TWiki web on direct mechanism. Would make sense to allow some attachments to be made explicitly public.
• For a delayed authentication, do we need a viewfileauth symlink, like viewauth?
  • We would. At work we use sessions and can force login at any time without all these auth scripts. Login is via certificate or username/password, both via an LDAP server. Note a few more plugin hooks could in Access.pm could make this available to other.
• Docs need to be done for URL rewrite so that admins of other web servers can configure the system. Any way without URL rewrite?
  • Not sure about this with current pub structure.

-- JohnTalintyre - 11 Oct 2003

Is there a patch available to do that? I especially like Colas's idea about a separate private directory (and this would remove the need for mod_rewrite).

-- PatriceFournier - 19 Feb 2004

Since I could not find the patches by JohnTalintyre, I reinvented the wheel. The patch below is again CairoRelease. In DakarRelease checkAccessPermission is already included. For performance reasons, I suggest taking the TWiki web out the redirection (to the bin/viewfile). My apache config looks like this:

  ScriptAlias /twiki/bin/ /filesystem/path/to/twiki/bin/
  Alias /twiki/pub/       /filesystem/path/to/twiki/pub/

  RewriteEngine on
  RewriteRule ^/twiki/pub/TWiki/(.*)$ /twiki/pub/TWiki/$1 [L,PT]
  RewriteRule ^/twiki/pub/([^\/]+)/([^\/]+)/([^\/]+)$ /twiki/bin/viewfile/$1/$2?filename=$3 [L,PT]

I did not test that against DakarRelease. Feedback welcome.

The above Apache conf is not safe . If the user uses // or /../ etc in the URL he can get access to the attachments anyway. -- BenWheeler and KennethLavrsen - 27 Jul 2006. See Bens improved regex below

-- OliverKrueger - 25 May 2005

The following is the code I use on DakarRelease. It's similar to the above, but should support hierarchical webs of arbitrary depth, and uses RewriteCond instead of a no-op RewriteRule to allow pub/TWiki to be unauthenticated.

   RewriteEngine on
   RewriteCond %{REQUEST_URI} !^/+twiki/+pub/+TWiki/+.+
   RewriteRule ^/+twiki/+pub((/+[^/]+)+)/+(.+) /twiki/bin/viewfile$1?filename=$3 [L,PT]
 

This would be a lot less complicated if viewfile accepted the full path as PATH_INFO instead of requiring the filename to chopped off and placed in the query string.

-- BenWheeler - 26 Jul 2006 (edited further by -- KennethLavrsen - 27 Jul 2006) (edited further again; simplified, now actually works with hierarchical webs -- BenWheeler - 25 Sep 2007)

It's probably a good idea to use an apache configuration which fails securely, instead of including an Alias for all of twiki/pub and then depending on RewriteRule to disallow access to all of twiki/pub that you don't want to be externally accessed. For example, the above configuration still has a bug -- it will (AFAICS) allow access to /twiki/pub/TWiki/../Secureweb/SecretTopic instead of directing it through viewfile.

What I do at my site is only include twiki/pub/TWiki in the Alias line, so that if the RewriteRule doesn't happen for any reason, the user is denied access. That's much better than allowing access if the RewriteRule fails.

        ScriptAlias /twiki/bin/ /filesystem/path/to/twiki/bin/
        Alias /twiki/pub/TWiki /filesystem/path/to/twiki/pub/TWiki

        RewriteEngine on
        RewriteRule ^/twiki/pub/TWiki/(.*)$ /twiki/pub/TWiki/$1 [L,PT]
        RewriteRule ^/twiki/pub/([^\/]+)/([^\/]+)/([^\/]+)$ /cgi-bin/twiki/viewfile/$1/$2?filename=$3 [L,PT]

-- AndrewMoise - 28 Jul 2006

The Apache::TWikiAuthen module provided in ApplicationAuthenticationAddOn also solves this problem. This module depends on SessionPlugin. The idea is : When user tries to access the attachment, Apache module extracts the topic name, webname, finds the username using session. It then checks the access using TWiki::Access::checkAccessPermission.

-- SopanShewale - 30 May 2005

I use the SessionPlugin for my TWiki installation. With the patch viewfile.pm.diff guest users still had access to restricted attachments. The new patch viewfile.patch works for me in this situation. This is a patch for the latest relase of Cairo.

-- HolmRauchfuss - 04 Oct 2005

Is this patch known to work with DakarRelease? I know ApplicationAuthenticationAddOn was partly merged with TWiki but attachments are still unsecured.

-- MartinCleaver - 12 Oct 2005

Related: PubsDirectoryShouldNotHoldSystemFiles AttachmentsUnprotectedByReadAccessRestriction SecurityAuditOnVisiblePubDir

-- MartinCleaver - 27 Oct 2005

Would someone be able to summarize the above ? For example, what is the best way to secure attachments in CairoRelease / DakarRelease ? Thank you

-- KeithHelfrich - 20 Aug 2006

Problem: If someone knows the exact URL of attachment (e.g. http://example.com/pub/Web/TopicName/File_Name.txt) the attachment is viewed without respecting the access controls. The attachments should follow the Access controls of topic.

You can solve this by installing Apache::TWikiAuthen module in system and .htaccess files in required /pub/webs directories which you want to put under strict access control.

I have modified the Apache::TWikiAuthen (this was included in ApplicationAuthenticationAddOn ) Module code for Dakar Release. The code is attached with this Topic.

The code is tested on Apache/1.3.37 (Unix) PHP/5.1.6 mod_perl/1.29 and TWiki 4.0.4 version.

How to Install? Sorry, I did not write the modules similar to modules written on cpan site. Its just .pm file.

[1]. Download the TWikiAuthen.pm [2]. Modify the following values

Add appropriate paths- My twikiroot is : /usr/local/apache/htdocs/dakar so my BEGIN block looks as follow:

BEGIN{
unshift @INC, "/usr/local/apache/htdocs/dakar/bin";
unshift @INC, "/usr/local/apache/htdocs/dakar/lib";
unshift @INC, "/usr/local/apache/htdocs/dakar/lib/CPAN/lib";
require 'setlib.cfg';
require 'LocalSite.cfg';
};

[3]. Copy TWikiAuthen.pm to lib directory of perl, I have copied it to /usr/lib/perl5/site_perl/5.8.0/Apache/ directory My perl version is v5.8.0 so above was the right directory for me.

[4]. Create .htaccess file pub/webs directories (e.g. my twiki root is /usr/local/apache/htdocs/dakar/ and want to apply strict restrictions on “Developer” web, I will create the .htaccess file in /usr/local/apache/htdocs/dakar/pub/Developer directory).

My .htaccess looks as follow:

PerlAccessHandler Apache::TWikiAuthen
PerlSetVar Access  NoGuest
PerlSetVar pubdir  "/usr/local/apache/htdocs/dakar/pub/"
PerlSetVar oopstemplate  "oopsaccessattachview"

Note my twiki-root is /usr/local/apache/htdocs/dakar. I tried to use getPubUrlPath from TWiki::Func but does not help in my case, I have added some ScriptAlias in Apache configuration file for above path.

[5]. Choose the appropriate oops template from your installation.

The oopstemplate variable is used to display the messege if some un-authorized user tries to access the attachments.

I have attached module, sample.htaccess with this topic. You can choose appropriate template from your installations.

What is the problem with Apache 2 and mod_perl 2.0?

The above module does not work with Mod_perl2.0, I hope to modify the module in future to support mod_perl2.0. The issue is because of mod_perl 2 and not because of apache2. It might work with Apache2 with mod_perl1.29, but I did not test it.

I was thinking to create a separate plugin/addon-shall I create that?

-- SopanShewale - 08 Sep 2006

Sopan: Very much Yes, please!

-- JoachimBlum - 30 Aug 2007

Was this abandoned?

-- MartinCleaver - 02 Nov 2007