> Because you mentioned "cookie-hacking": it is very easy to > take over a rails-session if you know the value of the > session-cookie. It is not possible to prevent that easily, > you can just make it harder by encrypting the whole session > (right from the beginning when the user enters the site, > and the cookie is created) by using https.https will encrypted the packets, not the data in the cookie, right, so https will prevent cookie hijacking, but not cookie hacking? Is the session id ''hackable'' ? Ie, if I hack my cookie and change the session id from n to n-1, can I pick up someone elses session? Cheers, Neville
On 6 Mar 2005, at 0:39, Neville Burnell wrote:>> Because you mentioned "cookie-hacking": it is very easy to >> take over a rails-session if you know the value of the >> session-cookie. It is not possible to prevent that easily, >> you can just make it harder by encrypting the whole session >> (right from the beginning when the user enters the site, >> and the cookie is created) by using https.Actually, you can specify that a given cookie is "secure". This means that it will only be transferred when the user is on a HTTPS page. Imagine this: A user logins in at https://site/login. He gets two cookies: session and session_secure. session_secure is marked secure, which means that the browser will only pass it when it''s on a https page. The user proceeds to browse the site at http://site/foo; here the browser only passes the session cookie and is identified correctly, but cannot perform sensitive operations. The user has now completed his shopping and charge the purchase to credit card (which has been added to the account earlier). He is redirected to https://site/checkout, where the browser now passes the session_secure cookie to identify the user securely. Because session_secure was issued to the user on an encrypted page after entering a username and password, it has never been passed in a cleartext communication. It can therefore now be used to identify the user securely, and we can allow him to charge the purchase to his credit card. The secure option is detailed in the cookies specification: http://wp.netscape.com/newsref/std/cookie_spec.html Guan
> Because session_secure was issued to the user on > an encrypted page after entering a username and > password, it has never been passed in a cleartext > communication. It can therefore now be used to > identify the user securely, and we can allow him > to charge the purchase to his credit card.Thanks for this ... I didn''t know about session_secure. But reading the spec indicates that this only ensures the connection is using https, so the session can''t be hijacked, but can still be hacked because the contents of the cookie are plain text [correct?] transmitted over https. IE, he can use his https connection and hack his own cookie. Imagine a hacker trying to get access to unauthorised details from your Rails app. He signs up and gets an account, id=66, and a session id=55. The session-id is stored in the cookie in plain text. He edits the cookie, changes the session-id to 54, and clicks the ''home'' action. Will Rails get the hacked session id from his hacked cookie? One way to protect against this type of attack is to generate an obscure sessionid based on say the ip-address and session creation time, and to check the ipaddress of the request against the ipaddress encoded in the session. hmmmm
Have you guys even looked at the session ID''s? Here are some that I had in my cookies on my machine. 94cd46844b62932bf58229e8f9204bda a05d07a06d50223dcca630097d8c7c81 678ecc42f9222cf71281b68ef7f0acf7 they look like md5 hashes to me, one way or another it''s going to be pretty hard to spoof someone elses session by guessing the hash On March 5, 2005 05:38 pm, Neville Burnell wrote:> > Because session_secure was issued to the user on > > an encrypted page after entering a username and > > password, it has never been passed in a cleartext > > communication. It can therefore now be used to > > identify the user securely, and we can allow him > > to charge the purchase to his credit card. > > Thanks for this ... I didn''t know about session_secure. > > But reading the spec indicates that this only ensures the connection is > using https, so the session can''t be hijacked, but can still be hacked > because the contents of the cookie are plain text [correct?] transmitted > over https. IE, he can use his https connection and hack his own cookie. > > Imagine a hacker trying to get access to unauthorised details from your > Rails app. He signs up and gets an account, id=66, and a session id=55. > The session-id is stored in the cookie in plain text. He edits the > cookie, changes the session-id to 54, and clicks the ''home'' action. Will > Rails get the hacked session id from his hacked cookie? > > One way to protect against this type of attack is to generate an obscure > sessionid based on say the ip-address and session creation time, and to > check the ipaddress of the request against the ipaddress encoded in the > session. > > hmmmm > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-- Scott Brooks Network Operations Manager Binary Solutions Ltd. sbrooks-7+OF9GBfT4Xe9wHmmfpqLOTW4wlIGRCZ@public.gmane.org
Neville Burnell <Neville.Burnell@...> writes:> But reading the spec indicates that this only ensures the connection is > using https, so the session can''t be hijacked, but can still be hacked > because the contents of the cookie are plain text [correct?] transmitted > over https. IE, he can use his https connection and hack his own cookie. > > Imagine a hacker trying to get access to unauthorised details from your > Rails app. He signs up and gets an account, id=66, and a session id=55. > The session-id is stored in the cookie in plain text. He edits the > cookie, changes the session-id to 54, and clicks the ''home'' action. Will > Rails get the hacked session id from his hacked cookie? > > One way to protect against this type of attack is to generate an obscure > sessionid based on say the ip-address and session creation time, and to > check the ipaddress of the request against the ipaddress encoded in the > session.By default, Rails handles session IDs for you in a fairly quality way, if you use it as supplied. It: + creates a cookie using an MD5 hash of data with tolerable amounts of entropy, though more would be desirable. + seems to avoid session fixation attacks by taking session IDs only in cookies (which are basically site-specific) and not in links (which can be used to communicate information cross-site). + makes a store for session state (e.g., @session[''user'']) available on the server, where it is found by session id and not subject to manipulation by the user. As a side observation, one risk to most Rails apps at the moment is the absence of any hard-to-guess data in forms and URLs, making it particularly subject to attacks where another site''s form is posted by the client''s browser to effect an action not intended by the user. Including a copy of the Rails session cookie in generated forms and testing it, on return, against the actual session cookie should prevent this attack (haven''t yet researched how to do this). For URL-based actions, you''d have to do something similar with the URL, which again would have to be for verification only (confirmed against the actual cookie). Rails sessions are based on the ruby stdlib ''cgi'' module, which notes: # The session id is an MD5 hash based upon the time, # a random number, and a constant string. This routine # is used internally for automatically generated # session ids. for the cookie, and then takes the first 64 bits of an additional MD5 hash of the session cookie to build the local session cache file name, meaning that any cookies whose hashes collide at that 64-bit value describe the same session. Still a huge space, but not as large as the cookie values would imply. The entropy in the current session cookie creation data (time of session including usec, process id, and a pseudorandom number from Ruby''s Kernel#rand -- which, according to the rdoc, is seeded with process start time and process ID) -- give a tolerable session key, but adding some higher-quality entropy (from /dev/random or OpenSSL::Random), if available (as it is on most current OSes), would be quite valuable. There''s not a huge amount of entropy in two times and a process ID. As several people have noted already, testing IP addresses creates more problems than it solves. Limiting the life of sessions is generally a good idea, however. IIRC, if you set a timeout (forgot where/how), Rails/Ruby CGI sessions do that on the server side simply by associating the times with the server-side session state, rather than encoding them in the cookie. Adam Majer writes:> AFAIK, session ids are generated and given to a user side as a cookie or > whatever so that we may later "identify" a user and their previous > authentication by that id. But this is not secure! It doesn''t matter if > we use https or "secure cookies" or some other crap. It doesn''t matter. > As soon as you trust the client to provide you with valid data, you are > in serious trouble. > > Rule #1 - NEVER trust client about authentication > Rule #2 - Use session ids to *HELP* you identify client''s authentication.You''re always going to trust the user to supply you with some form of indicator of his/her/its identity. Who else is going to supply it? The pair of rules is probably better stated as "Never accept client assertions of identity without validating them." To validate an identity if you''re running a stateful server is easy -- just look for a matching session ID to one originally generated randomly, as Rails'' default use of Ruby cgi does. For sites that maintain no server-side per-session state, a piece of server-signed data in the form of an HMAC over identifying data (username, issue time, and some lifetime indicator) substitutes well. - Lee