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. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
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 On Dec 25, 2005, at 4:25 AM, Onur Turgay wrote:> 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. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
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. -- Posted via http://www.ruby-forum.com/.
If the attacker guesses wrong, the session won''t be found in the session store and a new session will be generated. This is exactly the same case as when a user uses a session ID that is old and has been deleted from the session store by your session store clean up process. Do you just want to track when a session ID is invalid, or do you want to stop the generation of new sessions? ________________________________ From: Onur Turgay [mailto:onurturgay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] Sent: Sunday, December 25, 2005 3:26 AM To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: [Rails] understanding session fixation attacks 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. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
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 Onur Turgay wrote:> 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.
yeah your suggestion works. whenever a session id is forged, it''s refused and a new session is generated. thus I can compare internal session id with the cookie one and understand the forging. I was in doubt whether rails will generate a new session based on forged id; the answer is no. On 12/26/05, Tom Fakes <Tom-SpgrXpdGZSiNACpsiTyfug@public.gmane.org> wrote:> > > > If the attacker guesses wrong, the session won''t be found in the session > store and a new session will be generated. This is exactly the same case > as when a user uses a session ID that is old and has been deleted from the > session store by your session store clean up process. > > > > Do you just want to track when a session ID is invalid, or do you want to > stop the generation of new sessions? > > > > ________________________________ > > > From: Onur Turgay [mailto:onurturgay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] > Sent: Sunday, December 25, 2005 3:26 AM > To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > Subject: [Rails] understanding session fixation attacks > > > > 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. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >