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.
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.