How secure are sessions?
Patrick Doyle
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
Rick
Patrick Doyle
>
> 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
Robert Walker
> 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
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/.
Robert Walker
on Rails:
http://guides.rubyonrails.org/security.html
Patrick Doyle
Walker<rails-mai...@andreas-s.net> 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.
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
pharrington
> 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.
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 :\
Robert Walker
> 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.