Frederick Cheung wrote in post #1013777: > On Jul 29, 3:49pm, 7stud -- <[email protected]> wrote: >> "Ruby on Rails 3 Tutorial" says, >> > Which ruby on rails tutorial ? There are many ... >
It's the name of a book, which I think is fairly famous, and it happens to be available online at the author's website: http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions_controller but I've quoted the relevant parts. >> his own session id, and the [spoofer_session_id, user_id] will not be a >> pairing that Rails allows. > > Another important thing is that the data in the session store is > cryptographically signed - if you tamper with the cookie data then it > won't match the signature in the coookie > I don't see how that is relevant. It doesn't matter what's in a cookie if someone copies the cookie. Cryptographically altering the id 1, just makes it hard to guess the cookie. But in my scenario, the malicious user copies the cookie, so it doesn't matter if the cookie data is 'red' or 'XADFASDFASDFSADFASDFASDFASDF521374129348712398". >> the malicious user logs out of the user's account, won't rails store a >> token with a timestamp on the malicious user's computer? In fact won't >> the real user find it impossible to access his account when he gets back >> from >> vacation because his timestamp will no longer be valid? > > Again guessing because I don't know which tutorial you are talking > about, but I believe the pattern being discussed is one where whenever > the user logs in then the permanent token is replaced (and so any old/ > previously stolen tokens stop working). So you can still steal browser > cookies but they will only be useful until the user next logs in. If > the user's token is invalid then they can sign in using their username > and password. > Ah, I see. So the malicious user will have access to the account until the user returns from vacation. Then when the user visits the website, rails won't recognize him as a signed in user--but the user can still sign in with his name and password to gain access to the account. Subsequently, the malicious user's cookie won't work because of an invalid timestamp, and he won't be able to access the account anymore. However, what prevents the malicious user from changing the password, and permanently hijacking the account? -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
