"Ruby on Rails 3 Tutorial" says, == This session object makes the user id available from page to page by storing it in a cookie that expires upon browser close... Because of the way Rails handles sessions this process is secure; if a malicious user tries to spoof the user id, Rails will detect a mismatch based on a special session id generated for each session. ==
Okay, so the spoofer can guess a user id, e.g. 1, and create a cookie with that id, but when he logs into the app, rails will give the spoofer his own session id, and the [spoofer_session_id, user_id] will not be a pairing that Rails allows. == For our application's design choice, which involves persistent sessions--that is, signin status that lasts even after browser close--storing the user id is a security hole. As soon as we break the tie between the special session id and stored user id, a malicious user could [basically guess an id, e.g. 1, and create a cookie with that id and sign in.] == Okay, so in this case Rails wouldn't be able to spot the spoofer because the real user won't have a session id either when he logs in again. == To fix this flaw, we generate a unique, secure token [instead of using the user's id] based on the user's salt and id. == Okay, that just prevents the spoofer from easily guessing a user id: for instance guessing 1 won't work anymore. == Moreover, a [permanent token] would also represent a security hole--by inspecting the browser cookies, a malicious user could find the token and then use it to sign in from any other computer, any time. We solve this by adding a timestamp to the token, and reset the token every time the user signs into the application. This results in a persistent session essentially impervious to attack. == Whoa. What happens in this scenario: user logs in and rails stores a permanent, impossible to guess token with a timestamp in a cookie on the user's computer. The user goes on vacation for two weeks. While the user is on vacation, the malicious user gains access to the user's computer and inspects the cookies on the user's computer, and copies the token plus timestamp. The malicious user goes to his computer, creates a cookie with the copied token, and logs into the app. Won't the malicious user have free access to the user's account? When 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? -- 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.
