Item4048: EditTablePlugin: Password shown in URL params after template login on direct sort urls (authenticated setups)

While working outside my office, using our TWiki-based Extranet, I noticed that if you use the combination of TemplateLogin and PatternSkin, and try to access directly a topic that contains a table, the username and password are "shown" in the link built by TablePlugin, and thus are stored in the navigator cache alongside that page html.

The solution is simple, to add the following lines to the TWiki::Plugins::TablePlugin::Core::handler method:

        $plist =~ s/username=[a-zA-Z] ?//go;
        $plist =~ s/password=[a-zA-Z] ?//go;

Just after filtering the "sortcol" parameter (around line 929).

This may be just the tip of the iceberg. The main problem is that TablePlugin is using $cgi->query_string() to build the URL in the headers of the table. All plugins that do will have a similar security flaw.

Hope this helps.

-- TWiki:Main/RafaelAlvarez - 08 May 2007

Thanks Rafael. (I posted his e-mail to here.)

-- TWiki:Main/PeterThoeny - 10 May 2007

The filter needs to be more agressive. Passwords might contain any types of chars. Betetr to scan until & or ; delimiter or end.

-- TWiki:Main.PeterThoeny - 18 Jun 2007

May be proper solution is to filter out username and password in core code, not in plugin code?

-- TWiki:Main.PeterThoeny - 18 Jun 2007

3 other plugins use query_string():

TablePlugin/Core.pm:968
TagMePlugin.pm:780
TreePlugin.pm:96

-- TWiki:Main.ArthurClemens - 18 Jun 2007

Anyone looking at this one?

-- TWiki:Main.KennethLavrsen - 22 Aug 2007

Item2295 has some history on templatelogin and parameter passing.

-- TWiki:Main.SteffenPoulsen - 23 Aug 2007

I keep on pinging on this one. It was reported as a security issue on the security mailing list so we have a concerned customer and this is why it is hanging here being a release blocker.

-- TWiki:Main.KennethLavrsen - 27 Aug 2007

It seems I am unable to reproduce this one in current MAIN.

Is it possible to provide a little more detail in the steps needed to demonstrate the problem?

-- TWiki:Main.SteffenPoulsen - 27 Aug 2007

1. First you need to create a topic with a table that uses TWiki:Plugins.TablePlugin to sort by some column.
2. Make sure that TemplateLogin is used as the autentication method, and that

   view

   requires autentication
3. (Re)start the browser, and try to directly access the test topic created on the step 1.
   
4. Enter your login and password when queried by TWiki.
5. Check the links in the headers of the table: The login and password should be in plain sight.

-- TWiki:Main.RafaelAlvarez - 27 Aug 2007

while trying to be more generic in the password filtering, I found out that if the password have any character that is a special character, then there is the chance that the resulting URL will still have fragments of the password. This means that if & is the first character of the password then the full password will be present.

This is the regexp I'm using

        $plist =~ s/username=.*?&/&/go;
        $plist =~ s/password=.*?&/&/go;

Any idea on how I can work around this?

-- TWiki:Main.RafaelAlvarez - 07 Sep 2007

Perhaps cut to next known parameter name - or if user/pass can somehow be guaranteed to be the "last" parameters, perhaps it is a possibility to cut to the end of the string?

-- TWiki:Main.SteffenPoulsen - 07 Sep 2007

The password should always be passed url-encoded when passed to a GET. Otherwise ampersand and semicolon are impossible to pass to a GET.

-- TWiki:Main.CrawfordCurrie - 08 Sep 2007

I promised to fix this before the 4.2 beta, but have been unable to reproduce this using the above described procedure. No username or password parameters are in the sort headers (tried on MAIN but also on 4.1.2 release). There may be an interaction with other settings and/or plugins, would you mind posting your lib/LocalSite.cfg ??

-- TWiki:Main.KoenMartens - 10 Sep 2007

I have tried all sort of combinations of apache and template authentication. And I have tried with and without authenticating view (authenticating view with TemplateLogin is wrong by the way).

I cannot reproduce this one.

-- TWiki:Main.KennethLavrsen - 10 Sep 2007

I removed my temporary patch from our production installation (rev 14438), and tested this bug again. Effectively, is not happening in that revision, so there is a good chance that is not happening in MAIN.

BUT it is happening on rev 13668. The problem seem to have been "fixed" in the core, as the Plugin code that handle the parameters is exactly the same. So we have two options:

• Backport any change made to the core that fixed the issue.
• Put a fix in the plugin(what i'm doing now).

Anyway, if no one else can reproduce it on MAIN, then this should not be a release blocker anymore.

-- TWiki:Main.RafaelAlvarez - 12 Sep 2007

Assumed fixed then.

-- TWiki:Main.KennethLavrsen - 12 Sep 2007