==
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 uses a
cookie
to store a permanent, impossible to guess token with a timestamp 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 with timestamp.
The malicious user goes to his
computer, creates a cookie with the copied token and timestamp, 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?
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
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.
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 ‘1’ 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?
I’m just trying to understand the statement:
==
This results in a persistent
session essentially impervious to attack.
The author raised the possibility of a malicious user copying the cookie
on the user’s computer, but once that happens, it seems to me the
session is not impervious to attack.
data is ‘red’ or 'XADFASDFASDFSADFASDFASDFASDF521374129348712398".
Just above you wrote (or quoted) "Okay, so the spoofer can guess a
user id, e.g. 1, and create a cookie
with that id, " and I’m saying that you can’t spoof tails session
cookies like that.
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?
Most websites require you to supply the existing password to change a
password.
The only way we have determined that this is possible is with physical
access to the computer. As in any security scheme, that pretty well
trumps anything that doesn’t rely on the user logging in every time,
and time-limited sessions.
As with any form of security, it’s not a matter of absolutes, but
rather a balancing act between user discomfort and reasonable
protection. Nothing is foolproof, and the real problem is the user in
any case.
The only way we have determined that this is possible is with physical
access to the computer.
Are you saying that the malicious user can only gain access to the
user’s account while using the user’s computer? Or, is it true that
once the malicious user has a copy of the cookie, he can access the
account from any computer?
As in any security scheme, that pretty well
trumps anything that doesn’t rely on the user logging in every time,
and time-limited sessions.
I wasn’t critiquing rails, I was trying to understand why the author of
the book said the persistent session was impervious to attack–after
himself raising the specter of a malicious user gaining access to the
user’s computer. His explanation didn’t make sense to me–as far as I
could tell he was describing a process by which rails would store more
and
more complicated cookies on the user’s computer. But if a malicious
user gains access to a user’s computer, a complex cookie is equivalent
to a simple cookie–they can both be copied easily.
The only way we have determined that this is possible is with physical
access to the computer.
Are you saying that the malicious user can only gain access to the
user’s account while using the user’s computer? Or, is it true that
once the malicious user has a copy of the cookie, he can access the
account from any computer?
In the scheme you’ve outlined, I think it would work from any
computer. It could be extended though. I once implemented a scheme
whereby the ip address was part of the cryptographically signed info
so that the persistent cookie was valid only from that ip address
(obviously this has some limitations/problems too)
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?
Sure, but at this point the user is pretty throughly pwned anyways -
there’s no system that will protect the login here, short of ditching
the whole “persistent login” part and requiring the user to re-
autheticate on each visit.
himself raising the specter of a malicious user gaining access to the
user’s computer. His explanation didn’t make sense to me.
In answer to both of your questions, I was saying that physical access
to a computer where the user has checked the “remember me” option
completely trumps the security system. The computer becomes the key to
the lock, so if you steal that key… Which is another good reason to
always include a password lock on your screensaver, and disable any
auto-login convenience features. Especially on a laptop, but even on a
desktop that isn’t in a locked room.
As far as a copy of the cookie being useful, I’m not sure I can
comment. I think that it would work up until the point where the real
user logged in again, and the fact that the user had to log in again
might worry/alert a suitably clueful user that their remember me
cookie had changed. But I can’t say definitively, because I don’t know
what all goes into the cryptographic signature of the remember me
cookie. If it’s something based on the individual browser, then it
seems likely to me that it might fail on a different browser.
Walter
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.