Zope 2

Bug #367393
Comment #6

Comment 6 for bug 367393

Revision history for this message

Tres Seaver (tseaver) wrote on 2009-04-27: Re: [Bug 367393] Re: httponly for cookies

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

stephan_hofmockel wrote:
> Sorry for the upload crap :(
>
> 1) How should a good test look like for HTTPResponse ?? My current test
> calls HTTPResponse._cookie_list() directly and parses the output with
> regex.

Unfortunately, there aren't good tests for 'setCookie' at this point
(nothing which exercies the 'Domain', 'Max-Age', 'Comment', or Secure'
features). I have added such tests to the trunk and backported them;
they should serve as an example. See:

http://svn.zope.org/Zope/branches/2.11/?rev=99537&view=rev

> 2) This attribute prevents cookie access from JavaScript. So it is more difficult for malicious JavaScript code to hijack the session, with sending the current session-cookie to the attacker.
> You are right, most of the time data in a session is not critical and a attacker with a valid sessionID gains nothing.
> Unfortunately our application saves critical data in the session and uses (not only) this "special"-cookie for protection.
>
> I know this feature depends heavily on browser support and assists the
> "save critical data in a session" programming style. Nevertheless
> sometimes its unavoidable and other applications outside can profit from
> this additional attribute.

A couple of things:

- - The actual browser ID itself can't be precious data: it is a largely
opaque token, made up of both a random int and a timestamp.

- - Javascript-generated requests made from the same browser will still
carry along the browser ID cookie, even though the feature might
prevent JS from knowing the value of the cookie.

- - Javascript doesn't have access to cookies from domains other than
  those which match the current request; where is the attack vector
  which would expose a browser ID cookie to a malicious off-site
  script? Is the theory that there are browsers in the wild which
  have broken sandboxing (so that JS can see cookies from other domains)
  but which implement this feature correctly?

- - Cookies for non-HTTPS requests are *still* visible in clear to
man-in-the middle observers, and could therefore still be for
replay attacks.

All that being said, I'm fine with landing both parts of the patch, once
we have tests for the 'setCookie' / '_cookies_list' parts.

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ9bpr+gerLs4ltQ4RAnMXAKDQvstQTBnItf9hiAxLrl5SXxz+0gCgnsEf
oWSgM8Z+hnBRqFBsN66Q3Lo=
=kgkS
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

stephan_hofmockel wrote:
> Sorry for the upload crap :(
> 
>  1) How should a good test look like for HTTPResponse ?? My current test
> calls HTTPResponse._cookie_list() directly and parses the output with
> regex.

Unfortunately, there aren't good tests for 'setCookie' at this point
(nothing which exercies the 'Domain', 'Max-Age', 'Comment', or Secure'
features).  I have added such tests to the trunk and backported them;
they should serve as an example.  See:

http://svn.zope.org/Zope/branches/2.11/?rev=99537&view=rev

>  2) This attribute prevents cookie access from JavaScript. So it is more difficult for malicious JavaScript code to hijack the session, with sending the current session-cookie to the attacker. 
> You are right, most of the time data in a session is not critical and a attacker with a valid sessionID gains nothing. 
> Unfortunately our application saves critical data in the session and uses (not only) this "special"-cookie for protection.
> 
> I know this feature depends heavily on browser support and assists the
> "save critical data in a session" programming style. Nevertheless
> sometimes its unavoidable and other applications outside can profit from
> this additional attribute.

A couple of things:

- - The actual browser ID itself can't be precious data:  it is a largely
  opaque token, made up of both a random int and a timestamp.

- - Javascript-generated requests made from the same browser will still
  carry along the browser ID cookie, even though the feature might
  prevent JS from knowing the value of the cookie.

- - Javascript doesn't have access to cookies from domains other than
  those which match the current request;  where is the attack vector
  which would expose a browser ID cookie to a malicious off-site
  script?  Is the theory that there are browsers in the wild which
  have broken sandboxing (so that JS can see cookies from other domains)
  but which implement this feature correctly?

- - Cookies for non-HTTPS requests are *still* visible in clear to
  man-in-the middle observers, and could therefore still be for
  replay attacks.

All that being said, I'm fine with landing both parts of the patch, once
we have tests for the 'setCookie' / '_cookies_list' parts.

Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver@palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJ9bpr+gerLs4ltQ4RAnMXAKDQvstQTBnItf9hiAxLrl5SXxz+0gCgnsEf
oWSgM8Z+hnBRqFBsN66Q3Lo=
=kgkS
-----END PGP SIGNATURE-----