Secure Cookie flag

(Daytona) #1

I have my site set up for HTTPS and even added HSTS (using cloudflare though), however I would like to set the secure flag for my session ID cookie and maybe the other cookies as well.

It looks like _forum_session is the main cookie we would want to secure and on the secure flag is set.

I have the HTTPS setting in admin enabled:
Should the full url for the site (Discourse.base_url) be http or https? DO NOT ENABLE THIS UNLESS HTTPS IS ALREADY SET UP AND WORKING!

I’m also on the latest version of Discourse: v1.3.0.beta6 +98

Any simple way of doing this? Maybe I should make a plugin?

Edit: Supposedly the _t cookie is the real user session cookie

(Jens Maier) #4

Also, the actual session ID is stored in the _t cookie. _forum_session is Rails’ cookie session store and isn’t used to identify the current user. The data it contains is encrypted server-side. :wink:

(Daytona) #5

_forum_session and _t are HttpOnly by default.

_t is the session cookie? jeeze its just an MD5 hash. Weak and brute force-able

(Kane York) #6

No, it’s not an MD5 hash, it’s SecureRandom.hex, and the value is your auth token. If someone takes that _t value, they can act as you until you press Log Out.

(Daytona) #7

Thank you for the correction @riking, however it still has the same amount of entropy as an MD5 hash (32 characters a-f 0-9).

It’s just as vulnerable to brute force guessing. Especially with a site that has many users.

(Kane York) #8

No it doesn’t. It has a full 128 bits of entropy, as it’s not “backed” by the password.

Though I guess there could be a protection in place for trying to guess auth tokens? If we see an auth token that isn’t assigned to a user, chuck the request into RateLimiter and block the IP once it triggers.

(Daytona) #9

a form of intrusion detection is always nice, but that is just a band-aid and would go well along with a stronger session ID. A good session cookie is much longer and usually has at least 2 parts. Similar to the way _forum_session values are.

edit: also automated blocking of IPs can be problematic when you use a WAF like cloudflare as all requests are coming from them.

edit2: I will build attempt a proof of concept attacking my own site and submit a private disclosure to the developers. I did not mean to have this topic turn into a vulnerability analysis. I really just want to put the secure flag on my session cookies!!!

(Sam Saffron) #10

Very unlikely you would be able to do anything with the session cookie, this ships with Rails.

I have no idea what you are trying to brute force here but you would have no chance.

WRT _t cookie, its basically a GUID, so yeah, if you can try every single GUID in existence, eventually you will hijack a browser session.

(Jeff Atwood) #11

Ok, my bad, if that is the case, then why not turn on this cookie param automatically when the user ticks the HTTPS option in settings? Seems safe enough?

(Daytona) #12

I would like this! If you look at, it has the secure flag on it’s _t and _forum_session cookies.

(Jeff Atwood) #13

Hmm, unless nginx is adding that it should be coming from Discourse. Thoughts @sam?

(Sam Saffron) #14

There is a site setting you must enable if you are on https, I am pretty sure that forces the cookies to be secure.

(Jeff Atwood) #15

So basically this feature already exists :laughing:

(Daytona) #16

I’ve searched settings for cookies, https, ssl and have only found the one setting for https (which is enabled already)

(Kane York) #17

Try logging out and in again, are the reissued cookies Secure?

(Jeff Atwood) #18

Look at a few of our customers on HTTPS and check for the presence of that flag. Try – if Discourse, the software, is not adding that, then it must be coming from middleware somewhere.

(Daytona) #19

Already tried this. Logged out, deleted remaining cookies, logged in. no secure flag. Is it setting that I need to set then rebuild app?

That site has the secure flag on their _forum_session. Nothing about digital ocean (which I’m using) would prevent setting the cookie flag… its just apart of the response from the application. Since I’m just running a vanilla updated docker image, there’s nothing that would prevent the application from setting a secure cookie.

(Adam Curtis) #20

I’m also having an issue like @Daytona. I have enabled the https option (and tried logging out, destroying cookies etc) and it still doesn’t seem to be enabling the cookie option :frowning:

Our forum is here:

(Aaron Boushley) #21

@codinghorror @sam It looks like this cookie gets setup in the default_current_user_provider around line 69.

There is nothing there that looks at the use_https site setting and adds the secure flag.

Seems like this would be a pretty easy addition, open to a PR for this?

Setting the session token '_t' on the entire domain, not just my subdomain
(Sam Saffron) #22

Yes, but this needs to be VERY aggressively tested and we also need to consider backwards compat here.