GNOME Bugzilla – Bug 745579
blogs.gnome.org should not send session cookies in plaintext
Last modified: 2015-03-19 16:15:02 UTC
When I log in blogs.gnome.org/mcatanzaro only the login page and admin dashboard use HTTPS. I'm clearly still authenticated and can edit posts and return to the admin dashboard without further authentication, so my session cookie is obviously being sent in the clear. This is more than a little embarrassing since the focus of my blog is security and privacy. I'd rather HTTP not be offered at all.
I guess the session cookie is not marked as a secure cookie, or it would not have been possible for me to stay logged in. Exacerbated by issues like bug #745580 which result in the cookie sent in the clear even for HTTPS connections.
The following commit redirects all requests sent to port 80 to the HTTPS version of blogs.gnome.org: https://infrastructure.gnome.org/browse/puppet/commit/?id=564d0cc1d09ca5213b562ae334e035f02718eb91. Thanks for your report.
Gracias!
Hm, no, redirects are not sufficient (although I guess it is my fault for titling the bug incorrectly). For example, from my admin dashboard I click my username on the top of the screen, then Visit Site, the link is still http://blogs.gnome.org/mcatanzaro/ and my session cookie is still sent in the clear to the attacker (who can also simply not redirect me to the https site). To fix this you need to use relative links rather than hardcoding http:// (or, hardcode https:// everywhere instead). Lastly, if the session cookie is not marked as secure, then the attacker can just intercept js from any http:// page my browser visits and inject a request to http://blogs.gnome.org/mcatanzaro to get the session cookie. I [hope this isn't, doubt this is] an upstream Wordpress issue; if so they have a very serious problem in their security department. :)
After digging some more I found out the following things that we should do in order to accomplish a complete migration to HTTPS: 1. Every single blog has its own set of sql tables on the main database with its configuration 2. Every single blog has its own siteurl which may differ from the one globally set on the wp_sitemeta table, we can easily update all these with a python script 3. Adjusting the blog siteurl breaks the permalinks (luckily only by doing the move through the admin web UI, playing with mysql directly seems to work just fine), the fix is as straightforward as clicking on 'Save changes' under https://blogs.gnome.org/mcatanzaro/wp-admin/options-permalink.php. Can you confirm all the resources are correctly served from HTTPS for your blog now? if yes, I can move forward and fix all the hosted blogs.
(In reply to Andrea Veri from comment #5) > Can you confirm all the resources are correctly served from HTTPS for your > blog now? if yes, I can move forward and fix all the hosted blogs. Yes, I don't see any remaining problems regarding URLs on my blog -- thanks! However, an attacker can still trivially control my session if the session cookie is not marked secure. E.g. when I visit http://blogs.gnome.org/mcatanzaro -- a visit the attacker can trigger -- with Wireshark running, I see this in the HTTP header: Cookie pair: PHPSESSID=fn0sf6hpsg2ptgebidsij6rel0 That looks like a session cookie to me -- it should be marked as secure so that my browser does not send it to http://blogs.gnome.org, only to https://blogs.gnome.org! (I've logged out, so *presumably* that session token is no longer valid. It would be another nice problem if you could use that to log in as me after I logged out, which I haven't tested, but I'd like to assume Wordpress has done that properly....) See also: http://stackoverflow.com/questions/6821883/set-httponly-and-secure-on-phpsessid-cookie-in-php
Andrea, did you set Strict-Transport-Security? It seems Wordpress is rather stupid in its cookies. With above header we can force any http request to https, at least partly preventing this stuff. IMO wordpress should really figure out httpOnly and secure flags. I noticed you can also force httpOnly and secure for Set-Cookie. However, I guess httpOnly might be overdoing it.
Ok, actions taken: 1. Migrated all the hosted blogs siteurl and home option_name values from the wp_*_options table from http to https 2. Added Strict-Transport-Security in place: from curl -iI https://blogs.gnome.org/nacho --> "Strict-Transport-Security: max-age=31536000; includeSubDomains; preload" Michael, I'm marking the bug as resolved, please re-open if anything else is missing on our side.
As a side note make sure you don't have any hardcoded media content on your posts or the page will still be shown as having mixed content.
Super, I wish more sites used HSTS. That mostly solves the insecure cookie issue as well in supporting browsers (provided I don't use any mixed content, in which case it would be leaked anyway). Thanks!