Auth over SSL

[blackthorne]

There may be a security problem for all of you using Auth. Even if the
login process is done threw SSL the session should be also kept over
SSL or else you may be vulnerable to session hijacking (
http://en.wikipedia.org/wiki/Session_hijacking ) attacks.

My question is, is there a control to make auth methods and logged in
sessions to be kept over https and https only leaving at the same
time, public data to be transmitted as clear data?

Thank you,
Best regards

[Massimo Di Pierro]

You are correct. If you want to prevent session hijacking you need to
force cookies over https.

You can do this in your program

session._secure=True

But it is up to you to setup https.

On Jun 16, 5:43 am, blackthorne <francisco....@gmail.com> wrote:
> There may be a security problem for all of you using Auth. Even if the
> login process is done threw SSL the session should be also kept over

> SSL or else you may be vulnerable to session hijacking (http://en.wikipedia.org/wiki/Session_hijacking) attacks.

[Anthony]

On Thursday, June 16, 2011 9:48:47 AM UTC-4, Massimo Di Pierro wrote:

You are correct. If you want to prevent session hijacking you need to
force cookies over https.

You can do this in your program

   session._secure=True

 

Doesn't session.secure() do the same thing (i.e., sets session._secure=True)?

 

Also, setting a secure cookie tells the user agent to only send the cookie back to the server via a secure channel, but don't you also have to make sure that the cookie is originally delivered over https? What if the session first starts out over http (so the session cookie is initially sent insecurely) and then switches to https -- couldn't someone grab the session cookie on the initial send?

 

Anthony

[blackthorne]

It could.

I think it would be interesting to have a control to redirect by
default to https, whether it is a login or an authenticated session,
kind of what we already have for appadmin...

[Anthony]

On Thursday, June 16, 2011 11:12:16 AM UTC-4, blackthorne wrote:

It could.

I think it would be interesting to have a control to redirect by
default to https, whether it is a login or an authenticated session,
kind of what we already have for appadmin...

 

I don't think admin or appadmin redirect to https -- they just fail if the connection is not over https (or local).

[Massimo Di Pierro]

Correct. If you want to force https you need to configure apache or
other web server

[pbreit]

Is this a theoretical issue or an actual issue?

[Richard G]

Someone please correct me if I am wrong, but this issue is one of architecting your applications/environment properly.

If you only ever use https (ie: no http) then all is fine. 

If you use mixed http & https, then you likely want to set session.secure() (this will set the cookie 'secure' attribute, identifying that the browser should never send the cookie over a non secure channel). 

The issue is that first connection you use to obtain the cookie. If it is over a non secure channel, the server will send you a cookie with your session id and the secure attribute set. This is an issue in that a 3rd party can acquire your session id over this nonsecure channel.

Solution: Unfortunately the cookie is sent whether you are authenticated or not... I believe the only solution is to ensure all web2py calls are over a secure channel. Your settings can still identify that other calls may not be over secure channels though (think static files, etc... in which you bypass web2py). 

Thoughts??

[Anthony]

Maybe we should also have something like session.regenerate(), which could optionally be called by session.secure(). This would regenerate the session ID (but keep the existing session). So, upon login, you could call session.secure(regenerate=True), and it would change the session ID and secure the cookie. Would that work?

 

Anthony

 

[blackthorne]

Anthony: I don't really understand how would that solve the problem.
The problem has to do with transmission of the session cookie in a non
secure channel. Regenerate it won't solve the problem. We need to
enforce not to allow the transmission of authenticated sessions threw
non secure channels. I think this should be the default behavior.

pbreit: this is a real issue. Facebook, Twitter and Google Mail are
doing this as they acknowledged the problem. If you need proof of
concepts and you can get it easily with a simple firefox extension
that performs this attack called "Firesheep".

I think the solution requires to automatically redirect this data to
be transmitted over HTTPS and not even support logins and
authenticated sessions over non secure channels to prevent people's
mistakes. Makes no sense to allow logins and show login forms in a non
secure channel while there is a secure one. There is no need to change
anything in non authenticated sessions because they only provide, by
design, publicly available data so there we are ok.

Now, I know Massimo will probably not change this default behavior
because of backward compatibility (even though this is a real problem
requiring a fix) but that doesn't prevent us from making some option/
argument that will automatically enforce this behavior for an entire
application (at least) when activated.

What do you think?

Francisco

[Anthony]

On Thursday, June 16, 2011 6:02:00 PM UTC-4, blackthorne wrote:

Anthony: I don't really understand how would that solve the problem.
The problem has to do with transmission of the session cookie in a non
secure channel. Regenerate it won't solve the problem.

 

It will solve the problem of transitioning from an insecure/pre-login session to a secure/post-login session, which is a separate issue.

 

 

We need to
enforce not to allow the transmission of authenticated sessions threw
non secure channels. I think this should be the default behavior.

 

I'm not sure the framework should absolutely require SSL in order for the auth system to work at all.

 

Anthony

[blackthorne]

On Jun 16, 11:08 pm, Anthony <abasta...@gmail.com> wrote:
> On Thursday, June 16, 2011 6:02:00 PM UTC-4, blackthorne wrote:
>
> > Anthony: I don't really understand how would that solve the problem.
> > The problem has to do with transmission of the session cookie in a non
> > secure channel. Regenerate it won't solve the problem.
>
> It will solve the problem of transitioning from an insecure/pre-login
> session to a secure/post-login session, which is a separate issue.
>

I see you assume that the pre-login established session is the same
after login. I consider them as 2 different sessions, so yes
regenerate=True as you say is what I assume that should be the default
behavior when creating an authenticated session. At least, your
proposal should be available if we want to be able to warrant
authenticity.

> > We need to
> > enforce not to allow the transmission of authenticated sessions threw
> > non secure channels. I think this should be the default behavior.
>
> I'm not sure the framework should absolutely require SSL in order for the
> auth system to work at all.

Using any sort of method, providing authentication is more than just
saying who you are which is technically the only thing you are doing
when transmitting a session cookie in a non secure channel. it's about
proving that you are who do you say. While sending a username,
password to a website the user is trusting in the best practices on
handling those credentials safely. Those expectations should
be met by making the possible to prevent, at least, the publicly known
"cheap" attacks.
So, I'm not against the possibility of allowing non secure channels,
just defending this behavior as the one I consider that should be
default.

>
> Anthony

[pbreit]

I don't think the situation is that dire. The web has worked like this for 20 years and it hasn't been an actual issue. I think as long as the tools are available to go "all-SSL" that's fine.

[Anthony]

On Thursday, June 16, 2011 6:43:42 PM UTC-4, blackthorne wrote:

On Jun 16, 11:08 pm, Anthony <abas...@gmail.com> wrote:
> On Thursday, June 16, 2011 6:02:00 PM UTC-4, blackthorne wrote:
>
> > Anthony: I don't really understand how would that solve the problem.
> > The problem has to do with transmission of the session cookie in a non
> > secure channel. Regenerate it won't solve the problem.
>
> It will solve the problem of transitioning from an insecure/pre-login
> session to a secure/post-login session, which is a separate issue.
>
I see you assume that the pre-login established session is the same
after login. I consider them as 2 different sessions, so yes
regenerate=True as you say is what I assume that should be the default
behavior when creating an authenticated session.

 

Are you saying that once the user logs in, any existing session they had should be erased and a new one started? I don't think that's how it works now, and I'm not sure that would always be the thing to do, but maybe it should be an option. I was just suggesting regenerating the session id, but keeping the session itself.

 

 

> > We need to
> > enforce not to allow the transmission of authenticated sessions threw
> > non secure channels. I think this should be the default behavior.
>
> I'm not sure the framework should absolutely require SSL in order for the
> auth system to work at all.
Using any sort of method, providing authentication is more than just
saying who you are which is technically the only thing you are doing
when transmitting a session cookie in a non secure channel. it's about
proving that you are who do you say. While sending a username,
password to a website the user is trusting in the best practices on
handling those credentials safely. Those expectations should
be met by making the possible to prevent, at least, the publicly known
"cheap" attacks.
So, I'm not against the possibility of allowing non secure channels,
just defending this behavior as the one I consider that should be
default.

 

I hear you. Do you have a specific proposal for how auth and post-login routing should work? If a request comes in and the session includes an auth user, should web2py reject/redirect the request if it's not over SSL (at least that would be the default behavior, perhaps with the option to configure auth to allow non-secure sessions)?

 

Anthony

 

[pbreit]

Using session.secure() sets the "secure" flag on the session cookie which prevents it from ever being sent over a nonsecure channel. This should be sufficient to build a Firesheep-proof system.

[Anthony]

On Thursday, June 16, 2011 7:35:18 PM UTC-4, pbreit wrote:

Using session.secure() sets the "secure" flag on the session cookie which prevents it from ever being sent over a nonsecure channel. This should be sufficient to build a Firesheep-proof system.

 

I think setting the "secure" flag of the cookie simply tells the browser not to send the cookie back to the server over a nonsecure channel -- I don't think it prevents the server from sending the cooking to the browser in the first place (or even from accepting the cookie over a nonsecure channel). So, if you set session.secure() but are not using SSL, you'll still end up sending the cookie to the browser. There's also the scenario where the user session starts out nonsecure (i.e., pre-login on the non-SSL part of the site) and then switches to secure. The problem is, in that case, the session cookie has already been sent over a nonsecure channel before you end up calling session.secure().

 

Anthony

[pbreit]

That's exactly what the "secure" cookie flag prevents, sending the cookie over a nonsecure line. The problem as you note is that even if your server is set up to redirect nonsecure traffic to secure traffic, the cookies is still sent over in that first handshake. The "secure" flag prevents that. At least that's how I interpret the literature. The Firesheep guy provides more info: http://codebutler.com/firesheep-a-day-later

[Anthony]

On Thursday, June 16, 2011 8:26:47 PM UTC-4, pbreit wrote:

That's exactly what the "secure" cookie flag prevents, sending the cookie over a nonsecure line. The problem as you note is that even if your server is set up to redirect nonsecure traffic to secure traffic, the cookies is still sent over in that first handshake. The "secure" flag prevents that. At least that's how I interpret the literature. The Firesheep guy provides more info: http://codebutler.com/firesheep-a-day-later

 

As I understand it, the "secure" flag only tells the browser not to send the cookie to the server unless over SSL, but it doesn't prevent the server from sending or receiving the cookie without SSL. In any case, in web2py, session.secure() is useless if you don't actually have an https connection -- in that case, sessions will simply not work at all (because the browser won't be able to send the cookie back). The problem is if you have a non-https part of the site that requires sessions (which cannot use secure cookies) and then transition to a secure part of the site and secure the cookie -- in that case, because the cookie was initially not secure, there is a vulnerability.

 

Anthony

[blackthorne]

Well, a lot has changed in the past 20 years.
ARP Spoofing attacks emerged, Wireless shared channel communications
emerged, attackers multiplied and his methods got and more
sophisticated. Facebook, Twitter and are examples of very expensive
migrations related to social networks considered necessary that may
not deal with data as sensitive as some apps in web2py such as medical
records management, etc...

I invite you to take a look at the "other side". Checkout your
firewall logs on a public exposed device, checkout the releases found
on this website by a group of hackers called LulzSec (
http://lulzsecurity.com/releases/ ) and if you're interested, just
take a look at the portal exclusively dedicated to report attacks on
websites around the world on a daily basis ( http://www.zone-h.org/archive/special=1
).

[blackthorne]

> Are you saying that once the user logs in, any existing session they had
> should be erased and a new one started? I don't think that's how it works
> now, and I'm not sure that would always be the thing to do, but maybe it
> should be an option. I was just suggesting regenerating the session id, but
> keeping the session itself.
>

I think this just about semantics. Eegenerating the session id, as you
call it, is the right thing to do and I just added that should be
default when making a transition to a secure channel.

>
> I hear you. Do you have a specific proposal for how auth and post-login
> routing should work? If a request comes in and the session includes an auth
> user, should web2py reject/redirect the request if it's not over SSL (at
> least that would be the default behavior, perhaps with the option to
> configure auth to allow non-secure sessions)?
>

yes, something like
if auth.sslmandatory and request.env.protocol == 'https':
normal_auth_code and user funtions with a regenerated session

> Anthony

[pbreit]

Where should I put session.secure()? And is it session.secure() or session._secure=True?

[Anthony]

On Tuesday, June 21, 2011 7:13:34 PM UTC-4, pbreit wrote:

Where should I put session.secure()? And is it session.secure() or session._secure=True?

 

session.secure() simply does session._secure=True, so they are equivalent (though the former seems cleaner).

 

It simply results in the 'Secure' attribute of the session cookie being turned on, which doesn't happen until after the controller is run, right before the response is returned to the server. So, you can probably set it anywhere it makes sense, perhaps in a model. Note, once the cookie is set to Secure, the browser will only send it back over an HTTPS connection -- if the user goes to a non-HTTPS part of the site, the cookie won't come back, and web2py may generate a new session and (non) secure cookie (unless nothing is written to the session on the non-HTTPS part of the site).

 

Anthony

[Anthony]

Note, as far as I can tell, setting session.secure() doesn't restrict web2py from sending the cookie to the browser (i.e., web2py will send the cookie even if the connection isn't secure) -- it only tells the browser not to send the cookie back unless over a secure connection.

 

Anthony

[Massimo Di Pierro]

True.