Secure use of cookies and mixed use of https / http

Question

Many sites support https but do not use secure cookies. I want my site to use secure cookies, but to allow access to some content using http.

A reasonable way to do this, apparently, is to have a secure cookie for the real session and an unprotected cookie, which is just a flag to tell whether the user is registered or not (to display different things in the header, like an exit link, and no login link). This cookie does not contain any "real" information about the session, and it is simple that the site may display pages in a slightly different way for registered users compared to deleted ones on the http-sites of the site.

Having the whole site as https is another option, but it looks rather slower than plain http, and therefore not perfect.

Why do sites not use this setting and do not have secure cookies? The ability to steal cookies seems to make secure cookies now a necessity. Is there a better way to achieve the same?

Answer 1

The solution you propose looks like it will work if you don't mind unauthorized people who can view the unprotected (http) part of the site “as if they are logged in”, i.e. as long as the http part of the site does not contain any confidential information, and the only difference between registered and non-registered users is something harmless in the header.

The reason it is not used very often can be one of:

• This scenario may not be very common. Usually, if you are careful enough to ensure the security of your site, you would restrict the login session to this protected part only, or make the entire site always use HTTPS (for example, Paypal).
• There are pre-existing solutions that may be more secure, for example, registering with someone in the form of logging into HTTPS and supporting this session when transferring them back to HTTP. OpenID example. Also think that flickr or gmail: their page on the page is always HTTPS, but after the session starts, you switch to HTTP, while maintaining a secure session.

---

Update (August 2014)

Since I wrote this back in 2009, the practice of connecting to the secure access login screen, but returning to HTTP after logging in has almost disappeared.

The overhead of using HTTPS around the entire perimeter is no longer considered. The new SPDY protocol, first introduced by Google (now developed in HTTP / 2), is supported by a cross browser and major web servers and increases the speed of HTTPS.

And finally, confidentiality is considered more important than ever, even for actions that are not critical to authentication, such as writing comments, uploading photos, etc.

Google even recently announced that sites that are HTTPS-only will begin to benefit in search engine rankings.

Answer 2

From a security point of view, you should never trust any content sent over an insecure connection. Therefore, bearing in mind, then it is safe to use a cookie sent over an unencrypted connection only if the cost of theft or misuse of this cookie is zero.

Given this, most sites are designed in such a way that data is not allowed to "leak" between channels. In the end, the data coming from the encrypted side usually has privilege and therefore should not be allowed on the regular channel, while the data coming from the channel is unencrypted , potentially tampered with and should not be trusted.

If you have data that does not fit these generalizations, then feel free to do it as you please.

Answer 3

Passing cookies through HTTP is still bothering me. I think that the technique you described is the only reasonable way to protect cookies, allowing registered users to view HTTP pages as if they were logged in. However, I have rarely seen this implemented.

Why do sites not use this setting and have secure cookies?

I think the main reason for the lack of adoption is risk management :

• Theft of session tokens using eavesdropping is much more complicated than, for example, cross-site scripting (subject to the presence of vulnerability). You need access to a network (for example, a user's LAN or Internet service provider). Thus, in accordance with risk-based prioritization, developers must first solve XSS problems because they provide a much larger attack surface (the probability of attack is much higher).
• The same is true for fixing CSRF and UI (so-called click).
• If the business impact on hacked sessions is very large (for example, storing credit cards for later use in an online store), you might be better off limiting your entire HTTPS site.

Another reason may be related to usability. With your proposed scheme, you effectively manage two concurrent sessions for a single user. This is simple enough as long as the registered flag is the only state saved in an insecure session. If you can also change settings, such as language and country, in both sessions, this can become messy (implement or use).

Is there a better way to achieve the same?

From the Hacker Guide for Web Applications :

If HTTP cookies are used to transfer tokens, they should be marked as secure so that the user's browser never sends them over HTTP. If possible, HTTPS should be used for every page of the application, including static content such as help pages, images, etc.

Seriously, the whole site should use HTTPS. A few years ago, this would have been impossible, mainly because the CDNs did not provide HTTPS support. However, today it is mainly about balancing the costs of development and operation.

Answer 4

I fully understand that the recommended practice is simply to force the use of SSL throughout the site. However, there are certainly unique cases where the ability to choose and choose between HTTP and HTTPS can come in handy.

I came across a similar scenario like @Dsavid Gardner. My company uses a third-party provider to manage our part of the store on our site, and this store is located in the subdomain " https://store.mysite.com ". We have video content for 15 years, and our current video service provider breaks when the video is embedded in SSL. (I assume it draws resources from HTTP domains, but this is another problem the other day)

Of course, I could acquire SSL and go through the debugging process of two third-party providers, and also perform a search and replace on our entire database (or hhtaccess, but I was distracted) to correct any links to HTTP resources so that I could have a message in the header , say "Welcome" YourName ", but it just seems like a little redundant.

Here's a simple Javascript solution that I came across sets a workaround, insecure cookie based on secure cookies that are already set.

First I grabbed some javascript cookie functions . Go ahead and put this code in a secure part of your site:

 function readCookie(name) { var nameEQ = name + "="; var ca = document.cookie.split(';'); for(var i=0;i < ca.length;i++) { var c = ca[i]; while (c.charAt(0)===' ') { c = c.substring(1,c.length); } if (c.indexOf(nameEQ) === 0) { return c.substring(nameEQ.length,c.length); } } return null; } function setCookie(cname, cvalue, exdays) { var d = new Date(); d.setTime(d.getTime() + (exdays*24*60*60*1000)); var expires = "expires="+d.toUTCString(); /* Note, the W3 documents where I got this code didn't include the option to set the domain. I added this and it allows the cookie to be shared across sub-domains. Be sure not to add "www" */ document.cookie = cname + "=" + cvalue + "; " + expires + "; domain=.yourdomain.com"; } /*Now we check our cookies on our secure server to find out if the user is logged in or not. In my case, the First Name is stored as a cookie. */ var firstNameCookie = readCookie("the-secure-cookie-name"); // if(!firstNameCookie){ /* If the cookie doesn't exist, then the person isn't logged in. Add conditional logic here if you'd like (such as deleting any current logged in cookies from the HTTP portion of the site) */ } else { /* otherwise, we have a successful login. By grabbing the cookie via this javascript resting on the secure server, we haven't compromised our security. However, if we set a cookie with javascript right now, it won't be a secure cookie by default and we'll have access to it with HTTP on the subdomain */ setCookie("HTTPfirstName", firstNameCookie, 1.5); } */The clients first name is now accessible across subdomains in the cookie entitled "HTTPfirstName" */ 

In this case, the only thing we leaked to our HTTP server is the name of the client. However, if you want even more security, you can set your server settings to allow access to certain cookies (ie, "firstNameCookie") via an HTTP request and adds an extra layer of protection. You can find out how to do it here.

Of course, this is not the most ideal solution. In the future I plan to implement an SSL site, but with a simple javascript function to replace it, however, it is nice to have.