All the access control restriction can be easily circomvunted by using cross-web includes. For example, I have a web called "Restricted" that only some users can access. If a non-authorized user want to access that web, he can create a page in the "Test" web that contains that single line : %INCLUDE{"Restricted.WebHome"} %

My request is to have a configuration parameter for disabling the cross web include. I've seen that problem in the ChartPlugin.

I'm using TWiki version 01/dec/2001.

Thanks

-- PatrickValsecchi - 12 Sep 2002

If it hasn't already been done, I would recommend a call to

    if ( ! &TWiki::Access::checkAccessPermission("view", $wikiUserName, "", $theTopic, $theWeb) ) {
        return ""; # or an error message, e.g.  return "(Access to $theWeb/$theTopic is denied)";
    }

within the handleIncludeFile() subroutine (just after the test for different usage, or recursive loop check). This would allow cross web scripting, but deny access to restricted webs.

I just took a peek at cvs, and there's nothing like it in the latest copy.

And while I'm not too far off topic, how about changing the secureInclude check in that subroutine to

    $incfile =~ s/(^|\/)\.+/$1/goi;

or using a lookahead:

    $incfile =~ s/(?<=(^|\/))\.+//goi;

so as to remove all occurences of ../filename and any file that starts with a '.', e.g. .htpasswd, .htgroup, .bash_history, etc, similar to the way files preceded by a '.' are hidden in standard dir listings?

-- RobNorman - 13 Sep 2002

Actually, the above code doesn't work. By looking at it a little, it seems that functions checkAccessPermission, getPreferencesValue, ... are quite buggy as they assume that the web to test for access is in many global variables and/or do not pass the web to test as arguments, re-using the last one.

So patching this is more involved...

Moreover it may induce quite a performance hit. I think whoever fixes this may have to design some in-memory cache to avoid re-reading preference topics many times (basically make a cache on getPreferencesValue, but invalidate this cache on save, so that we may even get the benefit of the cache across invocations if we use mod_perl.

-- ColasNahaboo - 13 Sep 2002

There's another problem. If you look at the view script you'll see that if a user can't read a topic because they are not logged in, they can be switched to the viewauth script. We'll need something similar for protected =

Warning: Can't find topic ""."" = topics, otherwise the include will not work for anyone.

-- JohnTalintyre - 14 Sep 2002

I've got a partial fix for this working, shouldn't be too long before it fit for CVS. At present it's a bit slow and load preference you shouldn't really be able to see. But, by not doing a permission check on the TWiki and Main Webs I think it should work quite well.

I keep on saying at work that security isn't the key thing for a Wiki, but in many peoples' mind security is important, even in a Wiki. So about time I dealt with some of the holes. If I can't crack the perfomance angle I'll put a switch for this capability in TWiki.cfg

-- JohnTalintyre - 14 Sep 2002

I agree, for this kind of "a priori" requests I tends to talk people into releasing permissions after some use (tipically one month). However, I am now in a second phase where people want to use twiki for many uses, such as storing employee records, upper management meeting minutes, where privacy is definitely needed. I could set up one wiki server per use, but it can be hell to maintain (especially as config info is not in a central place).

For these "second circle" use, read protection is necessary in my opinion.

PS: on the viewauth problem: not beaing able to include any page with some protection from non-protected page is not really a problem, I think. Same problem with the search.

-- ColasNahaboo - 17 Sep 2002

Fix to security problem (ReadPermissionSometimesIgnored) now in CVS, so I've marked this as not suitable. I assume that a fix is better than disabling.

-- JohnTalintyre - 18 Sep 2002