is default Plack::Session secure enough?

[Kevin Goess]

Is the default Plack::Session setup generally secure enough to just use out of the box, or is it more of a suggested framework where should we put some thought into it?  I 'm considering things like adding an "expires" column to the database table and having sid_validate check the expiration of the session_id.  I notice that the documentation says it checks expiration

=item B<extract ( $env )>

This will attempt to extract the session from a C<$env> by looking

for the C<session_key> in the request params. It will then check to

see if the session is valid and that it has not expired.

but I don't see any expiration in the code. I see where it expires the *cookie* to the client, but not where it checks the expiration of the sessionid on the server side. Am I missing something?

I was also looking at doing user-agent hashing WRT session hijacking (http://phpsec.org/projects/guide/4.html), and/or linking the sessionids to userids.

[Tatsuhiko Miyagawa]

Hi Kevin,

On Tue, Dec 18, 2012 at 10:15 AM, Kevin Goess <kgo...@bepress.com> wrote:
>
> Is the default Plack::Session setup generally secure enough to just use out of the box, or is it more of a suggested framework where should we put some thought into it?

The actual default setup that uses Plack::Session::State is not
secure, as it is documented in the POD. I plan to deprecate the
module, or at least not make it a default and require developers to
set the state module explicitly:

http://search.cpan.org/~miyagawa/Plack-Middleware-Session-0.15/lib/Plack/Session/State.pm
| WARNING: parameter based session ID management makes session
fixation really easy, and that makes your website vulnerable. You
should really avoid using this state in the production environment
except when you have to deal with legacy HTTP clients that do not
support cookies.

> I 'm considering things like adding an "expires" column to the database table and having sid_validate check the expiration of the session_id. I notice that the documentation says it checks expiration
>
> =item B<extract ( $env )>
>
> This will attempt to extract the session from a C<$env> by looking
> for the C<session_key> in the request params. It will then check to
> see if the session is valid and that it has not expired.
>
> but I don't see any expiration in the code. I see where it expires the *cookie* to the client, but not where it checks the expiration of the sessionid on the server side. Am I missing something?

I guess you are not - expiring session is up to the developers (which
is not properly documented IMO) such as issuing DELETE queries with
the cron tab.

> I was also looking at doing user-agent hashing WRT session hijacking (http://phpsec.org/projects/guide/4.html), and/or linking the sessionids to userids.

I think it makes sense to add a new field like expires and does the
right thing to validate the session ID in the state module (and
probably Store module as well). The way it currently validates SID in
the state is kind of weird, and it probably has to be done in the
Store as well.

--
Tatsuhiko Miyagawa