Hi,
> I'm fairly convinced that we should at least give the user the option
> to be extra paranoid if they want to, and we should add additional
> documentation about potential issues.
>
> I just haven't had time to work on any of this yet, it's somewhere on
> my list - but if anyone else wants to
kmx wrote:
According to my tests against real application t0m is right and this
straightforward session fixation attack does not work.
On the other hand there exists (at least in my opinion) another sort of
session fixation issue in Catalyst application discussed here
http://rt.cpan.org/Public/B
On Wed, Jun 10, 2009 at 07:40:44AM -0700, Bill Moseley wrote:
> [1] Yes, it's a store, not a cache.
Ha! Morning post.
It's a cache not a store. But we use it as a store.
--
Bill Moseley.
mose...@hank.org
Sent from my iMutt
___
List: Catalyst@lists.s
On Wed, Jun 10, 2009 at 10:26:36AM +0100, Tomas Doran wrote:
> I specifically wrote a test for this, however it's a test and not
> comprehensive, and I can't see without spending time to take a detailed
> look again if your case is proved or disproved by this test.
This is a problem in our code
> http://dev.catalyst.perl.org/repos/Catalyst/Catalyst-Plugin-Session/0.00/trunk/t/live_session_fixation.t
>
>
> I specifically wrote a test for this, however it's a test and not
> comprehensive, and I can't see without spending time to take a
> detailed look again if your case is proved or dispro
On 6 Jun 2009, at 23:57, Bill Moseley wrote:
In other words, it provides a way for users to generate their own
session ids as long as it passes the validate_session_id method,
which doesn't take much.
http://dev.catalyst.perl.org/repos/Catalyst/Catalyst-Plugin-Session/
0.00/trunk/t/live_sess
I was looking over the session code and noticed this:
sub session {
my $c = shift;
$c->_session || $c->_load_session || do {
$c->create_session_id_if_needed;
$c->initialize_session_data;
};
}
My concern is the use of create_session_id_if_ne
