I have read a number of different tutorials that talk about adding a login page to an application that all contain very similar wording: "Of course, you would log in over an SSL connection". And I understand the theory of HTTP and the theory of packet sniffing well enough to know that, if I type in a password on a form, and that form gets sent unencryptedly to a server, then anybody with a packet sniffer could peek at that form as it goes whizzing by and look at the password. And I understand human nature enough to know that if something like that _could_ be done, then there are people out there who delight in doing things like that. OK, enough long winded babbling introduction. The tutorials I''ve read about logging into an application all store the user ID in the session. I presume that the "session" is a conceptual framework wrapped around a cookie. Here is where my knowledge of the theory of HTTP runs out. So I start to assume things. One thing that I assume is that, when a server places a cookie in a client''s browser, there must be something inherent in the protocol that would allow the server to retrieve that cookie. Now I start to wonder how secure sessions are? If only the login page is encrypted, what is to prevent somebody from sniffing the unencrypted cookie request and response as they go whizzing by to fetch later pages? Is there a provision for encrypted cookies? Do the client and the server share a secret when the cookie is first placed on the client (via the encrypted link) that is used to prevent the cookie from being used by a malicious party? I''m just curious about this, and, because I''m curious, and because I am really supposed to be writing an annual report, I thought this would be a good time to ask the experts about this burning issue. :-) --wpd
You could start here: http://www.rorsecurity.info/, download and read the book. On Jul 29, 9:26 am, Patrick Doyle <wpds...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I have read a number of different tutorials that talk about adding a > login page to an application that all contain very similar wording: > "Of course, you would log in over an SSL connection". And I > understand the theory of HTTP and the theory of packet sniffing well > enough to know that, if I type in a password on a form, and that form > gets sent unencryptedly to a server, then anybody with a packet > sniffer could peek at that form as it goes whizzing by and look at the > password. And I understand human nature enough to know that if > something like that _could_ be done, then there are people out there > who delight in doing things like that. > > OK, enough long winded babbling introduction. The tutorials I''ve read > about logging into an application all store the user ID in the > session. I presume that the "session" is a conceptual framework > wrapped around a cookie. Here is where my knowledge of the theory of > HTTP runs out. So I start to assume things. One thing that I assume > is that, when a server places a cookie in a client''s browser, there > must be something inherent in the protocol that would allow the server > to retrieve that cookie. > > Now I start to wonder how secure sessions are? If only the login page > is encrypted, what is to prevent somebody from sniffing the > unencrypted cookie request and response as they go whizzing by to > fetch later pages? Is there a provision for encrypted cookies? Do > the client and the server share a secret when the cookie is first > placed on the client (via the encrypted link) that is used to prevent > the cookie from being used by a malicious party? > > I''m just curious about this, and, because I''m curious, and because I > am really supposed to be writing an annual report, I thought this > would be a good time to ask the experts about this burning issue. > > :-) > > --wpd
On Wed, Jul 29, 2009 at 11:41 AM, Rick<richard.t.lloyd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > You could start here: http://www.rorsecurity.info/, download and read > the book.Thanks. I''ll do that, although I''ve realized in hindsight that my question is not specific to RoR. It''s much broader. But rorsecurity.info looks like a great place to start. --wpd
Patrick Doyle wrote:> OK, enough long winded babbling introduction. The tutorials I''ve read > about logging into an application all store the user ID in the > session. I presume that the "session" is a conceptual framework > wrapped around a cookie. Here is where my knowledge of the theory ofThe default for the current version of Rails does use a cookie based session store. However, this is not the only option. You can choose to store session data in the database, in a files on the server, or even in the URL.> HTTP runs out. So I start to assume things. One thing that I assume > is that, when a server places a cookie in a client''s browser, there > must be something inherent in the protocol that would allow the server > to retrieve that cookie.That is not exactly how cookies work. There is no separate request from the server to get cookies. One request might store a cookie in a client''s browser. Any cookies a client has stored for the target domain are sent along with every subsequent request. Meaning they are part of the request not a separate transaction. And yes, they would get encrypted in an SSL session.> Now I start to wonder how secure sessions are? If only the login page > is encrypted, what is to prevent somebody from sniffing the > unencrypted cookie request and response as they go whizzing by to > fetch later pages? Is there a provision for encrypted cookies? Do > the client and the server share a secret when the cookie is first > placed on the client (via the encrypted link) that is used to prevent > the cookie from being used by a malicious party?What you''re referring to here is called session highjacking. See http://en.wikipedia.org/wiki/Session_hijacking for more information about that. -- Posted via http://www.ruby-forum.com/.
This is also a good source of information on security specific to Ruby on Rails: http://guides.rubyonrails.org/security.html -- Posted via http://www.ruby-forum.com/.
On Wed, Jul 29, 2009 at 11:48 AM, Robert Walker<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Patrick Doyle wrote: >> OK, enough long winded babbling introduction. The tutorials I''ve read >> about logging into an application all store the user ID in the >> session. I presume that the "session" is a conceptual framework >> wrapped around a cookie. Here is where my knowledge of the theory of > The default for the current version of Rails does use a cookie based > session store. However, this is not the only option. You can choose to > store session data in the database, in a files on the server, or even in > the URL.I guess, in my mind, whether the session is stored in the cookie, or the key to the database containing the session is stored in the cookie, doesn''t make any difference. If somebody gets a hold of that cookie, they could hijack my session,. Not being anywhere close to being a security expert, I think it would be fairly trivial to solve this problem by encrypting an ever-changing cookie (i.e. one that includes the current time, or even just some random number, appended to the payload data) using a key that is set by the server when the cookie is first created via a secured link. This would, of course, require a change/enhancement to the cookie protocol and would have to be approved by the appropriate folks. Knowing the little bit I do know about security and encryption, I know that the fairly trivial solutions are usually fairly trivially broken, and that this issue is probably much more complex than I ever imagined (as I have learned from reading the links to which some folks have pointed me.) I suppose the only solutions to the session hijacking problem are to trust your neighbors (who can see all the packets you send) or to encrypt everything. But, as http://guides.rubyonrails.org/security.html points out, session hijacking by somebody who can sniff your packets, is only the tip of the iceberg when it comes to folks trying muck things up. Thanks for the info. --wpd
On Jul 29, 12:57 pm, Patrick Doyle <wpds...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Not being anywhere close to being a security expert, I think it would > be fairly trivial to solve this problem by encrypting an ever-changing > cookie (i.e. one that includes the current time, or even just some > random number, appended to the payload data) using a key that is set > by the server when the cookie is first created via a secured link. > This would, of course, require a change/enhancement to the cookie > protocol and would have to be approved by the appropriate folks.Sounds like you''re thinking of a nonce http://en.wikipedia.org/wiki/Cryptographic_nonce, and if course, implementing one to secure your sessions would require... no changes to any protocols at all. However, implementing it is nowhere close to trivial; you need to be fairly certain that no nonce is ever reused in the lifespan of your application, that the multiple running instances of your application don''t send the same nonce at the same time, and you need to keep in mind that the same app instance that issued a nonce might not be the same one that has to check it. A minute or so of googling finds no nonce session enabling Rails plugins, so if you ever are in the situation where this is a real concern, you''ll probably have to roll your own solution :\
pharrington wrote:> Sounds like you''re thinking of a nonce > http://en.wikipedia.org/wiki/Cryptographic_nonce, > and if course, implementing one to secure your sessions would > require... no changes to any protocols at all. However, implementing > it is nowhere close to trivial; you need to be fairly certain that no > nonce is ever reused in the lifespan of your application, that the > multiple running instances of your application don''t send the same > nonce at the same time, and you need to keep in mind that the same app > instance that issued a nonce might not be the same one that has to > check it. A minute or so of googling finds no nonce session enabling > Rails plugins, so if you ever are in the situation where this is a > real concern, you''ll probably have to roll your own solution :\Yes, and besides all this, what is the point of worrying about session key encryption, when all you need is to enforce use of SSL/TLS. Doing so makes all this complication go away. If one is passing sensitive information over a public wire in the clear, then session highjacking becomes a minor issue in comparison. There''s no point in reinventing this wheel. Experts far smarter than most of use have already solved this problem with SSL/TLS. -- Posted via http://www.ruby-forum.com/.