9

We currently have 2 sites http://www.foo.co.uk and https://secure.foo.com.

The www site does not have an SSL certificate and is on a different domain.

We have a login button on http://www.foo.co.uk that when clicked opens up an iframe of https://secure.foo.com with a form, when the user logs in it creates a session cookie on that domain (foo.com).

The session cookie then needs to be copied to foo.co.uk so what it does is redirects you to http://www.foo.co.uk/setcookie.php?session=abcd1234 which allows us to set the same cookie on the origin domain.

This is not a very secure solution so I have been looking into how to make this better - the best idea I have found is to send a hash using something like HMAC along with the params to the setcookie.php script and then verify it on the other end before creating the cookie.

Whilst this is better it doesn't prevent man in the middle attacks. Bearing in mind that www is not SSL secured I don't think you can prevent this completely, so the next best thing would be to include a timestamp in the hash to make it valid for 5 minutes.

Does anyone have any ideas on how I can make this better, or point out any pitfalls with this approach? I would be most grateful.

AviD
  • 72,138
  • 22
  • 136
  • 218
fire
  • 195
  • 1
  • 1
  • 4

2 Answers2

4

As you've noted already creating this token on the unencrypted www site will essentially remove the benefit of running over SSL for the secure site as an attacker can just sniff the token when it's transferred to the unencrypted site and then use it on the encrypted site to masquerade as the user.

Also having a link from the unencrypted site to the encrypted one where you log in leaves you open to an active MITM attack where the attacker redirects the request to their own site to take the credentials.

If there's not particular reason not to, you could just put SSL on both sites which would help to remove the risk mentioned above. The old main reason not to use SSL everywhere (performance) may not apply to you depending on how busy your site is an how heavily loaded it is.

Outside of that answers would depend on your architecture. For example, do the two sites share a database? If so could you have two different session values for a user (one for www and one for the secure site) and correlate them there?

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
2

login button on http://www.foo.co.uk that when clicked opens up an iframe

I would strongly recommend that this be changed such that the current page redirects to the SSL site or opens a new window - as a user I want to see 'https' in the address bar before I enter any authentication tokens!

Yes, using the same session id on both systems is insecure and exposes you to session hijacking. Ideally you would want to generate a different value which references the same session data. Since you're using PHP, adding your own session handler is trivial - you need to make some decisions about which side gets to read/write what on the other side. Using HMAC or any other functional mapping between the two session ids is not as secure as just creating a random new identifier and linking the two sessions within the data.

symcbean
  • 18,278
  • 39
  • 73