[OWASP-TESTING] final draft of the outline

Eoin Keary eoinkeary at hotmail.com
Thu May 12 06:36:09 EDT 2005

Looks like we are saying the same thing
>From: Stephen Venter <stephen.venter at gmail.com>
>Reply-To: Stephen Venter <stephen.venter at gmail.com>
>To: Eoin Keary <eoinkeary at hotmail.com>
>CC: daniel.cuthbert at owasp.org, owasp-testing at lists.sourceforge.net
>Subject: Re: [OWASP-TESTING] final draft of the outline
>Date: Mon, 9 May 2005 23:12:10 +0100
>A comment about secure cookies:
>On 5/4/05, Eoin Keary <eoinkeary at hotmail.com> wrote:
> > Authentication:
> > •     Token storage? (If not marked as 'secure' a cookie will be 
>stored on hard
> > disk)
> >
> > This is also true if the cookie not transient. Has an expiry date. The 
> > reason for the cookie flag to be set id to assure is can only be sent 
> > SSL
>As far as I have observed, the secure attribute for a cookie is only
>used to instruct the client web browser to transmit that cookie over a
>"secure", i.e. SSL/TLS/HTTPS, connection [thus not in clear text
>While it is the expiry date that determines whether it is written to
>hard disk or not (irrespective of whether or not the secure attribute
>has been set). So if the expiry date is set in the future, the cookie
>is written to disk for future use, even if the secure attribute is
>With reference to RFC2109 I like to describe the risk here as:
>This optional attribute "directs the user agent to use only secure
>means to contact the origin server" (per the RFC2109 of 1997:
>http://www.faqs.org/rfcs/rfc2109.html).  Therefore, without the
>"secure" attribute there is the risk that a user may have his web
>browser submit the cookie details in an insecure way, thus revealing
>potentially valuable details regarding his session.  This, in turn,
>could allow his session to be hijacked by a malicious unauthorised

Send a sexy animated wink with Messenger 7.0 - FREE download! 

More information about the Owasp-testing mailing list