8

I'm working on a web application which actually consists of two applications under the hood. One application is called account and handles all things related to user accounts such authentication, registration and management of the account. I also have an application we'll just call web.

The thing is that account listens on https://account.domain.com using SSL/TLS, and web listens on http://www.domain.com.

What options do I have for having people log in and authenticate account.domain.com and then redirecting them to www.domain.com where they're actually then logged in. As far as I know, you can't set up a cookie on account.domain.com and then have it work on domain.com as that would be a security risk.

Some background details about my applications:

  1. Written in the Go programming language.

  2. Makes use of the Gorilla Toolkit for most of the HTTP/HTTPS interfacing, URL routing and handling POST/GET parameters.

  3. Both applications live on the same virtual server.

What I'm looking for is a secure way to authenticate and manage a session across all subdomains of and the actual domain domain.com. I'm not particularly well versed in this subject, so aside from setting cookies, I don't know much.

Jesse Brands
  • 2,637
  • 8
  • 29
  • 36
  • Why do you think you cannot set a domain cookie with domain=domain.com from the domain account.domain.com? As long as the browser accepts domain.com as an ETLD+1 (see publicsuffix.org) it will work. – Volker Sep 01 '14 at 15:52
  • I'm not exactly sure what public suffix is or how it works, but on digging into it doesn't sound like this is supported by all major browsers. I need something that works for at least the latest versions of IE, Firefox, Opera, Chrome and Safari. – Jesse Brands Sep 01 '14 at 15:58
  • This may not answer your broader session management question, but you should be able to set a cookie on .domain.com from anything.domain.com--details about the public suffix list won't come up here. Just make sure [Cookie.Domain](http://golang.org/pkg/net/http/#Cookie) is .domain.com, not www.domain.com. (This also seems like a browser/HTTP/JavaScript question more than a Go question.) – twotwotwo Sep 01 '14 at 19:33
  • @Jesse: All major browsers determine the ETLD+1 in some way or the other. Publicsuffix.org is *the* reference here and is safe to use. All this has nothing to do with browsers but with what your "domain.com" really is. – Volker Sep 01 '14 at 21:19
  • 1
    The real problem here is that using a cookie across both domains (which means `Secure: false`) is that an attacker—someone sitting in a café or taking advantage of an XSS exploit—can easily modify (MITM; café) or read (XSS, if `HttpOnly: True`) the cookie contents. So be absolutely sure you're not storing anything critical or used solely to identify privileges. Better still would be to just put `www.domain.com` behind TLS/SSL too. – elithrar Sep 01 '14 at 21:49
  • @elithrar The cookie merely stores a session ID. The server actually keeps a token and a hash of the IP address + agent to identify the user. Any further advice I could use to identify the user? – Jesse Brands Sep 02 '14 at 12:36
  • 1
    What happens if someone reads the session ID? Or a user on a mobile device goes through a tunnel? – elithrar Sep 02 '14 at 12:42
  • The session ID, is, like I said, mapped to a token that is sent with each request to the browser (and has to be returned), and is also mapped to a hash of the user agent + ip address. This is obviously not completely fail safe, but it doesn't necessarily have to be. – Jesse Brands Sep 02 '14 at 18:01

1 Answers1

6

I'm not familiar enough with gorilla but something like should work:

var store = sessions.NewCookieStore([]byte("something-very-secret"))

func init() {
    store.Options = &sessions.Options{
        Domain:   "domain.com", //this
        HttpOnly: true,
    }
}

Basically you just have to set the cookie's domain to .domain.com (with the prefix .), there's a more detailed explanation in https://stackoverflow.com/a/1063760/145587

//edit

According to @Volker, the dot isn't needed (see comments).

Community
  • 1
  • 1
OneOfOne
  • 95,033
  • 20
  • 184
  • 185
  • 3
    There is no need to start the domain with a dot: "domain=domain.com" works just as well as "domain=.domain.com" on all browsers. See RFC 6265 which is widely adopted. – Volker Sep 01 '14 at 21:15