Heine

Update September 24, 2008 - Added a link to CVE-2008-3661 and "Fun Snags with Drupal Cookies"

Security theater consists of security countermeasures intended to provide the feeling of improved security while doing little or nothing to actually improve security.

A quite popular activity among Drupal site owners and extension developers (drupal, firefox) is to make sure certain page requests happen over a secure HTTPS connection, whereas the majority of requests is still done over an unencrypted HTTP connection. User logins are typically the target of this effort.

Now, unless your really value your password (because you happen to be Ben Bernanke and use the same password for the documents holding the future interest rate), this is only going to give you a false sense of security. I know, it is still a very warm and comfy feeling, but it won't be so comforting when some clown sees Mike Perry's presentation and takes away your site.

The problem

The problem is rooted in the fact that whenever you access your Drupal site via HTTPS the session cookie is not automatically marked as being secure. This means that the browser will handout the same cookie when you access your site via HTTP. As it contains your session ID unencrypted, an adversary can now use the session ID to wreak havoc on your site. As you can see, all the security mumbo jumbo can be trivially bypassed. Miky Perry's tool makes it even easier to execute these kinds of attacks.

The solution (sort of)

You need to make sure session.cookie_secure is set for all HTTPS connections. How depends on your server setup, but Apache usually has different vhosts for these types of connections, so there's ample room for configuration. The browser will never send a cookie marked as secure over an HTTP.

The solution breaks a quite popular scenario (think security theater again): login via SSL, but access to other pages as an authenticated user via HTTP. This worked because the browser used the HTTPS cookie for HTTP connections. As we have seen, this is extremely bad.

There is currently no secure way to have mixed HTTP/HTTPS access to a site (unless you can live with being Anonymous on HTTP, of course).

Issue #170310

Now, what does issue #170310 —the talk of the day— fix?

When you do configure your webserver correctly and the HTTPS cookie is set to be secure, accessing your site via HTTP causes your HTTPS cookie to be overwritten. This means that you have to login again via HTTPS. The patch on #170310 fixes a mere annoyance, but does not improve or affect security in any way.

Recommended reading

• SecurityFocus CVE-2008-3661
• Fun Snags with Drupal Cookies
• ActiveHTTPSCookieStealing.pdf.
• How to Properly Provide Mixed HTTP and HTTPS Support.