2

So I have a web service that is to be split up over several sub-domains.

So app1.xyz.com and app2.xyz.com.

Because Safari (last time I checked) does not allow for cookies to be shared across sub-domains like other browsers I need an efficient way to keep a user logged in as they go between the different sub-domains, on the same session.

On the face of it this should be an easy as sending the session_id in a the URL over https.

But is this good enough?

Both a cookie and a URL are sent over https so there is the same risk from decrypting the SSL certificate by snooping.

Is there anything else about sending the session_id in the URL that may be a issue?

Is there a better way, that is not over engineering things. Using oAuth seems like overkill to me, but maybe I am wrong?

3

You've misunderstood the cookie issue for Safari/Chrome, I think. Both of them implement the RFC properly, whereas Firefox/IE have been more relaxed in the past.

The normal rules are:

  • Setting a cookie for xyz.com does not allow any subdomains to read it.
  • Setting a cookie for .xyz.com allows all subdomains to read it.
  • Setting a cookie for app1.xyz.com only allows the app1 subdomain to read it, but not other subdomains.

Some browsers bend these rules slightly, and instead allow cookies without the . prefix in their domain to be read by subdomains anyway, regardless of the fact that the RFC says otherwise. If I remember correctly, IE/FF used to do this, but I think they've come more into line in recent versions.

On the face of it this should be an easy as sending the session_id in a the URL over https. But is this good enough? Both a cookie and a URL are sent over https so there is the same risk from decrypting the SSL certificate by snooping. Is there anything else about sending the session_id in the URL that may be a issue?

You should never put session identifiers in the URL. There are a bunch of reasons for this:

  • They're visible on screen, so they're susceptible to shoulder surfing or leakage via shared screenshots.
  • They get saved, unsafely, in browser history. This could be used to recover session tokens in a multi-user desktop environment.
  • URL parameters usually get logged by proxies, load balancers, and web servers, which means active session tokens are saved in the clear in your logs.

It's just bad practice to send them in URLs - if you did it, and I pentested your app, I would certainly flag it as an issue.

Is there a better way, that is not over engineering things. Using oAuth seems like overkill to me, but maybe I am wrong?

As noted above, I don't think your original problem is actually a problem, you just need to set the correct domain for the cookie. Once you've done that, you should be ok.


Also, since you've mentioned that you're using HTTPS for everything, I highly recommend the setting the Secure flag on your cookies to ensure that they can't be transmitted over plaintext HTTP. You should also look into setting a HTTP Strict Transport Security header to avoid sslstrip attacks. But these are just additional suggestions to improve security cheaply, and aren't directly related to your original question.

1
  • It seems you are right, the last time I checked was about 5 years ago so I suppose things have changed. Or I was doing something wrong at the time.
    – Kile
    Jun 18 '15 at 21:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.