Hi all, 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. The problem is after a session id was generated for a given user, that session id can be used by anyone to hijack the session. The only way around this is to verify that a given request is actually originating at the same client as the authentication. How do you do this? Create a table that will hold all your connections. Something like this, session_id bigint not null primary key, client_ip cidr, last_access timestamp, ...other stuff... good place to stick your session data :) After you authenticate a given user, store their IP address and their session id in the above table. Then when the session id doesn''t match the authenticated IP, well, you throw the user back to the authentication screen. And check session id against the IP before doing ANYTHING else. The only problem with this is if the user requests can reach you with different NATs/proxies or the client''s IP address changes. A "don''t bind session ID to my IP" checkbox would be good for clients with crappy ISPs. This also illustrates why IPv6 is needed now, not 10 years from now (NAT is killing security). "secure_cookies" are useless when it comes to security, because again, they rely on the client to send you what you sent them. DON''T do that. - Adam
Allow user to choose whether to bind their sesion to IP would be too complicated for normal users. And most users would not know whether they are sitting behind a load-balancing proxy that may alter their source IP.. Secure cookie is not foolproof, a cross-site scripting attack can still recover this cookie, but used in HTTPS session will at least prevent the session cookie from being sniffed... refer to OWASP on best practice for session management. Right now, the most feasible solution is to reduce session timeout to prevent session replay. On Sat, 05 Mar 2005 21:14:53 -0600, Adam Majer <adamm-/bNIpuWcnMP1bCa13UOFLWXnswh1EIUO@public.gmane.org> wrote:> Hi all, > > 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. > > The problem is after a session id was generated for a given user, that > session id can be used by anyone to hijack the session. The only way > around this is to verify that a given request is actually originating at > the same client as the authentication. How do you do this? > > Create a table that will hold all your connections. Something like this, > > session_id bigint not null primary key, > client_ip cidr, > last_access timestamp, > ...other stuff... good place to stick your session data :) > > After you authenticate a given user, store their IP address and their > session id in the above table. Then when the session id doesn''t match > the authenticated IP, well, you throw the user back to the > authentication screen. And check session id against the IP before doing > ANYTHING else. > > The only problem with this is if the user requests can reach you with > different NATs/proxies or the client''s IP address changes. A "don''t bind > session ID to my IP" checkbox would be good for clients with crappy > ISPs. This also illustrates why IPv6 is needed now, not 10 years from > now (NAT is killing security). > > "secure_cookies" are useless when it comes to security, because again, > they rely on the client to send you what you sent them. DON''T do that. > > - Adam > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Sat, 05 Mar 2005 21:14:53 -0600, Adam Majer <adamm-/bNIpuWcnMP1bCa13UOFLWXnswh1EIUO@public.gmane.org> wrote:> Hi all, > > 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. > > The problem is after a session id was generated for a given user, that > session id can be used by anyone to hijack the session. The only way > around this is to verify that a given request is actually originating at > the same client as the authentication. How do you do this? > > Create a table that will hold all your connections. Something like this, > > session_id bigint not null primary key, > client_ip cidr, > last_access timestamp, > ...other stuff... good place to stick your session data :) > > After you authenticate a given user, store their IP address and their > session id in the above table. Then when the session id doesn''t match > the authenticated IP, well, you throw the user back to the > authentication screen. And check session id against the IP before doing > ANYTHING else. > > The only problem with this is if the user requests can reach you with > different NATs/proxies or the client''s IP address changes. A "don''t bind > session ID to my IP" checkbox would be good for clients with crappy > ISPs. This also illustrates why IPv6 is needed now, not 10 years from > now (NAT is killing security).There''s another problem, a large number of people are behind transparent proxy servers. A large number of them are load balanced and a large number of *them* don''t share an external IP address. In my day jobs I''ve seen lots of cases where one session spanned multiple IP addresses as they obviously switched between proxy servers. You probably don''t want to log people out randomly (from their perspective). AOL made up a large percentage of these cases.> "secure_cookies" are useless when it comes to security, because again, > they rely on the client to send you what you sent them. DON''T do that.It''s *good enough* for the majority of situations, you probably don''t want to use them for your nuclear missle launching application. But 99% of web apps are fine with it.> - Adam > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers Koz
Thanks Adam ... I suspected this. -----Original Message----- From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Adam Majer Sent: Sunday, 6 March 2005 2:15 PM To: Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: [Rails] Session ids and identification Hi all, 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. The problem is after a session id was generated for a given user, that session id can be used by anyone to hijack the session. The only way around this is to verify that a given request is actually originating at the same client as the authentication. How do you do this? Create a table that will hold all your connections. Something like this, session_id bigint not null primary key, client_ip cidr, last_access timestamp, ...other stuff... good place to stick your session data :) After you authenticate a given user, store their IP address and their session id in the above table. Then when the session id doesn''t match the authenticated IP, well, you throw the user back to the authentication screen. And check session id against the IP before doing ANYTHING else. The only problem with this is if the user requests can reach you with different NATs/proxies or the client''s IP address changes. A "don''t bind session ID to my IP" checkbox would be good for clients with crappy ISPs. This also illustrates why IPv6 is needed now, not 10 years from now (NAT is killing security). "secure_cookies" are useless when it comes to security, because again, they rely on the client to send you what you sent them. DON''T do that. - Adam _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Sunday 06 March 2005 03:25, Michael Koziarski wrote:> On Sat, 05 Mar 2005 21:14:53 -0600, Adam Majer > > "secure_cookies" are useless when it comes to security, because again, > > they rely on the client to send you what you sent them. DON''T do that. > > It''s *good enough* for the majority of situations, you probably don''t > want to use them for your nuclear missle launching application. But > 99% of web apps are fine with it.What if you want something more secure, like a voting app? Would it be possible to create something really secure using the certificates that most browsers support? -- Lee.
On Sun, 6 Mar 2005 07:48:24 +0000, Lee Braiden <jel-OMY0mCUCxqbPG/DoapTOmA@public.gmane.org> wrote:> On Sunday 06 March 2005 03:25, Michael Koziarski wrote: > > On Sat, 05 Mar 2005 21:14:53 -0600, Adam Majer > > > "secure_cookies" are useless when it comes to security, because again, > > > they rely on the client to send you what you sent them. DON''T do that. > > > > It''s *good enough* for the majority of situations, you probably don''t > > want to use them for your nuclear missle launching application. But > > 99% of web apps are fine with it. > > What if you want something more secure, like a voting app? Would it be > possible to create something really secure using the certificates that most > browsers support?If your site requires more security than ''random cookies over ssl'' you should probably look into two factor authentication. I hear it''s reasonably common in europe for you to have to enter the code from a one time pad whenever you want to transfer money. That way, when people steal your login and password, the worse they can do is look at how much money you have. In reality the biggest threat you have is your own users. Attacks against your system are hard to pull off, it''s much more likely that one of your users will download BR1tn3ySp34rs.mp3.exe and install a keystroke logger.> -- > Lee. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers Koz
On Sunday 06 March 2005 08:26, Michael Koziarski wrote:> On Sun, 6 Mar 2005 07:48:24 +0000, Lee Braiden <jel-OMY0mCUCxqbPG/DoapTOmA@public.gmane.org> wrote: > > What if you want something more secure, like a voting app? Would it be > > possible to create something really secure using the certificates that > > most browsers support? > > If your site requires more security than ''random cookies over ssl'' > you should probably look into two factor authentication. I hear it''s > reasonably common in europe for you to have to enter the code from a > one time pad whenever you want to transfer money. That way, when > people steal your login and password, the worse they can do is look at > how much money you have.Not sure what you mean by two-factor, unless you mean distributing a key offline, which will be out of the question (usually, at least). How would an OTP-based webapp work, exactly? The best approach I''m currently aware of to validate a session on each request is to simply check that the basic request data: IP is the same, session isn''t too old. But as I understand it, pre-supplied web certificates encode each request with a known-good keypair from that user, so you can be pretty certain of who they are, in much the same way as being certain of who a GPG-signed/encrypted email is from. That would be quite ideal, I think. Am I wrong in thinking that this is how it works? If that is how it works, how would I go about implementing that in Rails? Is anything necessary, or is it all part of SSL?> In reality the biggest threat you have is your own users. Attacks > against your system are hard to pull off, it''s much more likely that > one of your users will download BR1tn3ySp34rs.mp3.exe and install a > keystroke logger.I''m not so worried about an individual being silly enough to compromise their own identity by indirect means. I see that as more of a social/education issue than a webapp security issue, except in the case of organised attack where many computers might be compromised to rig a vote. Primarily, my app will be aimed at a Free Software crowd (at least initially), so I expect their local security to be relatively good anyway. -- Lee.
On Sun, 6 Mar 2005 09:27:16 +0000, Lee Braiden <jel-OMY0mCUCxqbPG/DoapTOmA@public.gmane.org> wrote:> On Sunday 06 March 2005 08:26, Michael Koziarski wrote: > > On Sun, 6 Mar 2005 07:48:24 +0000, Lee Braiden <jel-OMY0mCUCxqbPG/DoapTOmA@public.gmane.org> wrote: > > > What if you want something more secure, like a voting app? Would it be > > > possible to create something really secure using the certificates that > > > most browsers support? > > > > If your site requires more security than ''random cookies over ssl'' > > you should probably look into two factor authentication. I hear it''s > > reasonably common in europe for you to have to enter the code from a > > one time pad whenever you want to transfer money. That way, when > > people steal your login and password, the worse they can do is look at > > how much money you have. > > Not sure what you mean by two-factor, unless you mean distributing a key > offline, which will be out of the question (usually, at least). How would an > OTP-based webapp work, exactly?It wouldn''t. If your application doesn''t require enough security to distribute OTPs to your customers, then you should be fine with a secure cookie approach. All you need is to distribute batches of 100 codes to your users which they then have to enter when doing any high-value action.> The best approach I''m currently aware of to validate a session on each request > is to simply check that the basic request data: IP is the same, session isn''t > too old.The IP of customers changes all the time, see my earlier post on load balanced transparent proxies. You can do it this way, but some of your customers will just be logged out for no reason. Is that the user experience you''re after?> But as I understand it, pre-supplied web certificates encode each request with > a known-good keypair from that user, so you can be pretty certain of who they > are, in much the same way as being certain of who a GPG-signed/encrypted > email is from. That would be quite ideal, I think. Am I wrong in thinking > that this is how it works? > > If that is how it works, how would I go about implementing that in Rails? Is > anything necessary, or is it all part of SSL?I don''t know anything about this approach sorry.> > In reality the biggest threat you have is your own users. Attacks > > against your system are hard to pull off, it''s much more likely that > > one of your users will download BR1tn3ySp34rs.mp3.exe and install a > > keystroke logger. > > I''m not so worried about an individual being silly enough to compromise their > own identity by indirect means. I see that as more of a social/education > issue than a webapp security issue, except in the case of organised attack > where many computers might be compromised to rig a vote. Primarily, my app > will be aimed at a Free Software crowd (at least initially), so I expect > their local security to be relatively good anyway.Once your application moves beyond the free software users, this is going to be your biggest problem. Seriously. The press will blame you. http://www.stuff.co.nz/stuff/sundaystartimes/0,2106,3208355a6005,00.html> -- > Lee. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers Koz
On Sunday 06 March 2005 18:36, Michael Koziarski wrote:> On Sun, 6 Mar 2005 09:27:16 +0000, Lee Braiden <jel-OMY0mCUCxqbPG/DoapTOmA@public.gmane.org> wrote: > > Not sure what you mean by two-factor, unless you mean distributing a key > > offline, which will be out of the question (usually, at least). How > > would an OTP-based webapp work, exactly? > > It wouldn''t. If your application doesn''t require enough security to > distribute OTPs to your customers, then you should be fine with a > secure cookie approach. All you need is to distribute batches of 100 > codes to your users which they then have to enter when doing any > high-value action.Well, I didn''t quite say that. It''s a Free Software app for online FS projects, so there simply won''t can''t be a core organisation mailing out security material. I don''t require PERFECT security for this, but I do want to make it as good as possible, obviously. Hence these questions :)> The IP of customers changes all the time, see my earlier post on load > balanced transparent proxies. You can do it this way, but some of > your customers will just be logged out for no reason. Is that the > user experience you''re after?Well, it wouldn''t be so bad if they had to login once-per-session. But yeah, IP isn''t ideal, in many ways. Not an approach I''d personally favour.> Once your application moves beyond the free software users, this is > going to be your biggest problem. Seriously. The press will blame > you.lol, good point :) -- Lee.