Forum: Ruby on Rails understanding session fixation attacks

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
043efdc2a79afbfec84696f50fd42163?d=identicon&s=25 Onur Turgay (Guest)
on 2005-12-25 12:33
(Received via mailing list)
is there a way that, our application can understand wheteher the session
id
sent from the browser is forged or created by rails? I understand that
if
the attacker guesses session id, theres nothing we can do about it; but
can
we understand if he/she is trying to guess by creating random session
ids.
Fd5e69c9c61627b86b9115fc1303596c?d=identicon&s=25 Jim Jeffers (Guest)
on 2005-12-25 20:07
(Received via mailing list)
Can't we just pass another unique key as a pair to validate the
session?  It'd be much harder to randomly guess two matching keys.
That would be my simple solution.

----------------------------------------
Jim Jeffers
"A trustworthy individual."
www.DontTrustThisGuy.com
(480) 235-5201
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2005-12-25 20:52
Jim Jeffers wrote:
> Can't we just pass another unique key as a pair to validate the
> session?  It'd be much harder to randomly guess two matching keys.
> That would be my simple solution.

In principle there is no difference between one key and two keys, using
two keys is the same as doubling the key length. But this is not
necessary, the chance that someone can guess the 64 bits of the Rails
session ID is virtually zero.
D6d48c40f1aee60c7dbfba68770148b2?d=identicon&s=25 Anocha Yimsiriwattana (Guest)
on 2005-12-26 06:23
(Received via mailing list)
How about keep the session id in the session itself. Then compare with
what
ever the browser send back. This way, we can verify it. However, I don't
know it actually works. Never try.

Tom
This topic is locked and can not be replied to.