Is this an insecure implementation of multi-site sessions?

Question

I have a multi-site Magento (A PHP eCommerce platform). Accounts are shared across sites, but sessions are not, so you have to log in to each site individually. I'm interested in sharing these sessions.

I found an answer on the Magento stack exchange. Sharing Sessions Between Stores with Different Domains. The recommendation is this:

cookies.php

setcookie("frontend", htmlspecialchars($_GET['SID']), time() + 86400);

example1.com

<?php $sessionId = Mage::getSingleton('core/session', array('name' => 'frontend'))->getSessionId(); ?>
<img src="https://example2.com/cookie.php?SID=<?php echo $sessionId; ?>" style="display:none;" />

I'm trying to wrap my head around the full security implications of this. If I'm not mistaken, this URL becomes all that is needed to log in as a user.

All of our sites are HTTPS only, so I think that helps prevent anyone listening in on traffic from getting this URL, correct?

One issue I might see is that if someone is at the physical computer, they would have access to that URL and could use it to login from a different computer, which would otherwise be impossible without the password. Expiring the session prevents against that though, right? If so, sessions are currently pretty long so carts stay alive longer, so how short should the sessions be?

In short, Is this an insecure implementation of multi-site login sessions? If so, can this approach be made secure?

Answer 1

A lot of SSO systems work this way. But there's a bit more to it than just a couple of lines of code, specifically:

• use cookies for sessions with the usual httponly and secure flags
• when a request for an authenticated service is received but without a valid session, redirect the user to the SSO (this needs some special handling around POST and DELETE/PUT/PATCH if used)
• if a session already exists on the SSO or the user passess authentication, redirect the user back to a special landing page in the application with a token in the URL (because that's the only polite way to get data across domains)
• at the landing page, establish a link back to the session, set the sesison cookie and redirect to the originally requested page (note that some older browsers ignored cookies set in a 302 response)

HTTPS [...] helps prevent anyone listening in on traffic from getting this URL, correct?

The key word here is "helps". It doesn't prevent the URL from appearing in the history.

so how short should the sessions be?

Trying to fix an issue of leaking the session cookie by shortening the session timeout is not the right way to go. A better approach is to have the SSO send back a single use token which the application can then use to resolve the session or authenticate access to the session, e.g. (on the SSO)

if (authenticated()) {
    $secretsid=encrypt(session_id(), SERVERSIDEPASSWORD);
    $_SESSION['otp']=uniqid();
    $return_url=add_get_arg($app_landing_url, array(
      'secretsid'=>$secrestsid,
      'OTP='=>$_SESSION['otp'],
      'original_requested_url'=>$originally_requested_url)
    );
    header("Location: $return_url");
    exit;
}

and at the landing page....

if ($_REQUEST['secreetsid']) {
    $sid=decrypt($_REQUEST['secretsid'], SERVERSIDEPASSWORD);
    if (looks_like_a_valid_session($sid)) {
          session_id($sid);
          session_start();
          if ($_SESSION['otp']==$_REQUEST['otp']) {
             unset($_SESSION['otp']);
             header("Location: $_REQUEST[original_requested_url]");
             exit;
          } else {
             // bad OTP
             log_bad_session_transfer();
             exit;
          }
    } else {
          // might be naughtiness, might be a bug
          log_bad_session_transfer();
          exit;
    }
 } else {
    // must have got here by accident - send them back to SSO
    redirect_to_sso();
    exit;
 }

An alternative way to resolve / validate the token would be to make a direct HTTP call from the landing page back to the SSO (i.e. server to server, not via the browser) and ask it to resolve the SID based on the toekn received from the browser.