Session Management

[TheRook]

This bug relates to the confidentiality and performance of the sessions used by engineauth. In short, webapp2_extras.sessions is more secure and flexible.

The following is the HTTP response produced at the end of the OAuth negotiation which establishes the authenticated session state:

HTTP/1.1 307 Temporary Redirect
set-cookie: _eauth="eyJ1c2VyX2lkIjoiNTczMzk1MzEzODg1MTg0MCIsInNlc3Npb25faWQiOiI1NzMzOTUzMTM4ODUxODQwIn0\075|1369787314|a370913d395205858ebd0c3b5f4809f18b26aa4a"; Path=/
location: http://localhost:8080/
content-type: text/html; charset=UTF-8
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache
Content-Length: 258
Server: Development/2.0
Date: Wed, 29 May 2013 00:28:34 GMT

This set-cookie http response header is not setting the HTTPOnly and Secure cookie flags. These two flags are intended to prevent the compromise of the session id. Having the HTTPOnly flag set means that an attacker cannot read this cookie value using an XSS payload. The secure cookie flag insures that this cookie value will never be transmitted over an insecure channel. By transmitting the cookie value in plaintext, an attacker can hijack an authenticated session using a tool like Firesheep.

Firesheep:
http://en.wikipedia.org/wiki/Firesheep

Cookie security flags:
https://www.owasp.org/index.php/HttpOnly
https://www.owasp.org/index.php/SecureFlag

Transport layer protection:
https://www.owasp.org/index.php/Top_10_2010-A9-Insufficient_Transport_Layer_Protection

The base64 used in the _eauth cookie value is as follows:
eyJ1c2VyX2lkIjoiNTczMzk1MzEzODg1MTg0MCIsInNlc3Npb25faWQiOiI1NzMzOTUzMTM4ODUxODQwIn0\075

This base64 decodes to the following
{"user_id":"5733953138851840","session_id":"5733953138851840"}

The session_id is used to reference a session sate stored in the Google datastore. This design is a blending of session management paradigms.

One paradigm is storing the session state in the Cookie as a serialized object. This value is attacker controlled so it must be protected with an hmac and a secret key. The hmac value in the set-cookie at the top of this post is: a370913d395205858ebd0c3b5f4809f18b26aa4a.

The other paradigm is setting the cookie value to be a large random value. This value alone is used to lookup session sate in the database.

Both paradigms are secure on their own, and there is no security benefit of blending these two approaches. It should be up to the user which method they would like to use. The use of an HMAC means that an efficient RESTful api uses one database lookup per API call. Storing state on the server side reduces bandwidth consumed by the client.

A possible solution to this problem is to expose some of the configuration options used in "webapp2_extras.sessions". For example this class provides three datastore backends, and the ability to add new backends.

The three are "securecookie", "datastore", and "memcached":
(http://webapp-improved.appspot.com/api/webapp2_extras/sessions.html#webapp2_extras.sessions.SessionStore.get_session)

"webapp2_extras.sessions" also exposes the two security related cookie flags by specifying the "secure" and "httponly" using the "cookie_args" parameter.

[kylefinley]

@TheRook,

Sorry for the late response.

Thank you for taking the time to investigate these security issues. You have brought up some important issues, here and in other issues, I definitely think using webapp2_extra.sessions switching to bcrypt, etc. are things that need to be addresses.

Up to this point I have been pretty much the sole contributor to EngineAuth. Recently, though, I haven't had the time to keep the project current. I've been contemplating turning the project into more of a community effort.

• Creating a github account - adding collaborators
• Moving the domain to engineauth.appspot.com

You seem to have solid understand of sessions and web security. Would you have the time, or would you be interested in leading some of these efforts?

Thanks for all of you help so far, and please don't feel any pressure. I just wanted to put that out there in case you might be interested.

Kyle

[TheRook]

I work as a pentester and days are long. Do what you can, some of these
fixes are pretty simple. I'll check back in when I have some free time.

On Thu, May 30, 2013 at 3:48 PM, Kyle Finley [email protected]:

@TheRook https://github.com/TheRook,

Sorry for the late response.

Thank you for taking the time to investigate these security issues. You
have brought up some important issues, here and in other issues, I
definitely think using webapp2_extra.sessions switching to bcrypt, etc.
are things that need to be addresses.

Up to this point I have been pretty much the sole contributor to
EngineAuth. Recently, though, I haven't had the time to keep the project
current. I've been contemplating turning the project into more of a
community effort.

• Creating a github account - adding collaborators
• Moving the domain to engineauth.appspot.com

You seem to have solid understand of sessions and web security. Would you
have the time, or would you be interested in leading some of these efforts?

Thanks for all of you help so far, and please don't feel any pressure. I
just wanted to put that out there in case you might be interested.

Kyle

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-18713462
.