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
- First you need to create a topic with a table that uses TWiki:Plugins.TablePlugin
to sort by some column.
- Make sure that TemplateLogin is used as the autentication method, and that
view
requires autentication
- (Re)start the browser, and try to directly access the test topic created on the step 1.
- Enter your login and password when queried by TWiki.
- 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