Well, if there's nothing confidential, chances are that there's no risk to data.
More precisions on what you'd like to protect against might be useful here.

--
David Rajchenbach-Teller
CSO, MLstate

On Mar 21, 2011, at 2:52 PM, Pankaj Upadhyay wrote:

In such a case, the primary risk, regardless of how the cookies are
flagged, is that they may be still set over HTTP (e.g., by
network-level attackers on wifi networks). Thus, any reliance on them
within the HTTPS context should be done with extreme caution.

/mz

What do you mean by "secure cookies"?

1. Do you mean the =secure bit?

2. Do you mean some other control like checksums, or cryptographic obfuscation?

In general if the cookies have no value then I wouldn't waste time on
them. However, if users log into the application, and one or more
cookie values control their authentication and authorization, then the
cookies may have value.

#1: setting the =secure bit simply prevents the browser from
transmitting the cookies over non-SSL connections on the same site
(leaking them in cleartext). If the cookies don't matter, this doesn't
matter. =secure can break the application if there are non-SSL
functions that need the cookies marked =secure.

#2 has implementation overhead, and can have performance implications.
Not worth the time if the app has no confidential data and the cookies
aren't used for anything sensitive or that has security implications
(like session).

There are probably more important things to focus on in the
application, like ensuring that there are no exposures to injection
attacks. etc.

Arian Evans
==Secure

On Mon, Mar 21, 2011 at 6:52 AM, Pankaj Upadhyay
mr.p.upadhyay@gmail.com wrote:

Important things here to understand about the cookie. Cokkie generally
contains user session ID or may be some other non senstive data.But if
the session ID compromises than it will create a huge risk.

On 3/21/11, Michal Zalewski lcamtuf@coredump.cx wrote:

--
Thanks & Regards

Robin Tiwari
Security Anlayst

Pankaj,

On Tue, Mar 22, 2011 at 12:52 AM, Pankaj Upadhyay
mr.p.upadhyay@gmail.com wrote:

If confidentiality (i.e. commercial in confidence information,
sessions cookies) is not a concern then can you clarify the business
drivers for HTTPS?

--
Regards,
Christian Heinrich

http://cmlh.id.au/contact

Let me rephrase my question:

Firstly by secure cookie, I meant the setSecure flag. One of our customers
has a site running on HTTPS. I am not sure about the business drivers for
that but this site is using some CMS and divided into two broad sections -
one is public site with no authentication and other is secure site with the
authentication. Home page of the site comes under the public site and when
browser requests for the home page, response sets a CMS session cookie and
this cookie's secure flag is not set.

As per the best practices, this cookie should be secure but my question was
even if it is not secure and can be compromised, is there 'any other' risk
associated with it in the present scenario?

BTW thank you everyone. I think I have got my answers. Thanks for the
replies.

On Tue, Mar 22, 2011 at 11:18 AM, Christian Heinrich <
christian.heinrich@cmlh.id.au> wrote:

--
Thanks,
Pankaj Upadhyay