Various guides to the use of Perl's taint checking, such as the Secure Programming Guide, Taint Checking FAQ and perldoc perlsec, make it clear that you should always 'filter in' the legal characters for a particular value when untainting a variable. TWiki.cfg's $securityFilter adopts the opposite approach, meaning that it's easy to forget some character that should be blocked.

In addition, I've noticed quite a few places in the code where a value is untainted without checking it. This makes taint checking somewhat less useful, to say the least

I think we should go for a 'filtering in' approach, as part of improving the security of TWiki.

Another security issue that should be addressed is the use of system() with a single argument - since this can call a shell (and does, in some TWiki usage), this is not very secure and is one reason that taint checking is required. Using two arguments, with the first one being the pathname of the program, avoids this.

This is quite important for Internet sites, but is also an issue for intranets where an attacker might be able to use TWiki as a point of entry into a server. For example, it would be handy to use TWiki attachments to manage software downloads by customers, but it would need to be very secure to place it in the demilitarised zone (DMZ) of a firewall, i.e. exposing it to the Internet with relatively valuable contents.

Please do not scare me like that! I promised my boss that TWiki is safe, because many smart, security-aware programmers reviewed the code and made sure all security issues are fixed. It was exactly his point if TWiki does not have some TWiki-specific exploits, which TWiki-aware hacker may abuse.

What changes I need to do in standard TWiki installation? Can be changes you suggested above be included in upcoming BeijingRelease?

TWiki is probably reasonably secure, for the reasons you mentioned - e.g. it uses taint mode and generally tries to be careful about how it does things. However, there are some areas where this needs to be improved, particularly if you are going to put it on a high-profile Internet site, or on a webhost where all CGI scripts run as 'nobody'.

My comments are mainly based on 'good practice' security guidelines, and seeing a few questionable untainting actions in the code, not on knowledge of specific holes - this sort of continuous review of security is what the better OpenSource projects, e.g. OpenBSD, use to make sure they don't have holes. This probably looks a lot more scary because it is being discussed in an open forum - similar issues exist in commercial software but they are handled behind closed doors

We had some security reviews in the past and made changes based on that, so TWiki is already fairly secure. Nevertheless, there is always room for improvements!

TWiki's $securityFilter does not the 'filter in' because it is difficult to list all allowed chars, especially in an environment other than English. Once we have a good i18n we can switch over to the 'filter in' approach.

There are a few places in the code where a value is untainted without checking it, this is because it has been checked previously in the chain. Not pretty and is error prone, but it works. This should be fixed.

Thanks for the explanation - sounds quite reasonable, but there are some areas where filtering-in would be safer, particularly when handling URLs, e.g. in TWiki.pm at line 208 (TWikiAlphaRelease), the following code is potentially vulnerable. Since we have a limited set of characters allowed in topic names, I don't see a problem with just filtering in based on alphanumerics:

Just one (ignorant) question -- will this break those tricky little scripts that let us make changes on a host system that doesn't allow us root access? (Richard, I think you know the scripts I mean, as I think you suggested one to me once.)

Umm, did I not just read that Perl is giving up hope of ever being sufficiently secure
via taint analysis, etc.?
(Cannot find the reference, but I swear I found it when reviewing Perl 5.6.1 or Perl 5.8 recently.)
No serious secure system administrator would rely on Perl.
It is better to use techniques such as Using Unix Groups For TWiki Security,
and chroot boxes, if you want to go that far.
Use Perl security as an extra level, to decrease the chance of a twiki server
being taken down;
but use OS security to decrease the chance of a security hole in TWiki or Perl
bringing down the entire computer.