Motivation
TWiki::Request
supports the '
secure' option for cookies when the connection is over
HTTPS but
TWiki::LoginManager
does not.
As a result, the only way to keep TWiki and the browser from happily sending the session cookie over plain
HTTP is to run TWiki over
HTTPS only, not even having a redirect from
HTTP to
HTTPS.
Description and Documentation
I suggest that a configurable extension to
TWiki::LoginManager
is made to set the '
secure' option for its cookie and only sending it if the
TWiki::Request
has the
secure
flag on.
Examples
Impact
Implementation
Here is the hard-wired change I made to
_pushCookie()
that works for me:
sub _pushCookie {
my $this = shift;
return unless $this->{twiki}->{request}->protocol() eq 'https';
my $cookie = CGI::Cookie->new( -name => $TWiki::LoginManager::Session::NAME,
-value => $this->{_cgisession}->id(),
-secure => 1,
-path => '/' );
...
--
Contributors: StefanWalter - 2010-08-27
Discussion
What are the implications if the cookies are not set?
May be safer to add this feature conditionally with a new configure flag, such as
{Sessions}{DisableUnsecureCookies}
. Use default 0?
--
PeterThoeny - 2010-09-30
If a site is accessible using HTTP and HTTPS the behavior so far is that you can authenticate (for instance over HTTPS) and then switch back to HTTP and still work as authenticated user. Users may feel that this is handy. After restricting the cookie to HTTPS a user will notice that he will be treated as
TWikiGuest when going back to HTTP. Depending on the navigation means (other than through
WikiWords) or usage patterns (multiple tabs, bookmarks,etc.) this could feel strange to the user.
A configuration flag to enable this conditionally is perfect. I would propose to use
EnableSecureCookies
though. What default to use is more a question of which TWiki customers are mostly impacted by this and their attitude towards security.
I could live with a default of
0
and a note in the release notes for 5.0.1 to give the people who want the additional security a hint. Defaulting this to
1
would impact sites that treat HTTP and HTTPS as the same and may cause trouble.
--
StefanWalter - 2010-10-01
This proposal needs some
TLC and testing to fold into the
JerusalemRelease..
--
PeterThoeny - 2011-08-23
Thanks for bringing this up, I'm now using this adaptation:
# Push the standard cookie
sub _pushCookie {
my $this = shift;
my $cookie;
if( $TWiki::cfg{Sessions}{DisableUnsecureCookies} ) {
# only send session cookies over secure connection when configured so
return if $this->{twiki}->{request}->protocol() ne 'https';
$cookie = CGI::Cookie->new( -name => $TWiki::LoginManager::Session::NAME,
-value => $this->{_cgisession}->id(),
-path => '/',
-secure => 1 );
} else {
# cookie over http and https
$cookie = CGI::Cookie->new( -name => $TWiki::LoginManager::Session::NAME,
-value => $this->{_cgisession}->id(),
-path => '/' );
}
...
--
WillemEngen - 2012-08-09
And now that we're at cookie security, does any (known) javascript use the sessionId? If not, it may be useful to also include the httpOnly flag as well.
--
WillemEngen - 2012-08-09
I changed the status to
ParkedProposal due to long inactivity. Anybody feel free to claim and implement this feature.
--
Peter Thoeny - 2015-06-18