1

I'm studing a case that I have a RESTful backend (php-based) and a hybrid HTML+JS+PHP front-end in different subdomains:

backend.example.com  <-- A RESTful API to provide some XHR requests.
*.example.com  <--  Any other domains on the same server that use the same PHP Session.

A way to initiate a persistent session in PHP without the placement of a session cookie is creating your own session id and setting it using session_id() function.

Disabling session cookie storage in fact doesn't allow me to maintain session across sub domains. So I implemented a Session Manager Class, to control all my classes' lifecycle, and to allow sharing the session across subdomains:

   public static function sessionStart($name, $limit, $trusttoken){

            (...)

    $userip = $_SERVER['REMOTE_ADDR'];
    $userbrowseragent = $_SERVER['HTTP_USER_AGENT'];

    $id = md5($userip . $salt .  $userbrowseragent  . $sessionname); //Creating unique ID

    session_id($id);                
    session_start();

            (...)
   }

Is it a secure way to share sessions in the same server but using diferent subdomains?

Note

  • The Sessions will be read only in server side(PHP files)
  • I don't care about trusting XHR requests.
  • I'm avoiding exposing session id in requests.
  • It's not possible to use SSL.
  • It's not possible to use SSL??? I would not expect much security without that... – Gudradain Oct 30 '14 at 19:56
  • 1
    I'm avoiding exposing session id in requests. How do you maintain session state without transmitting session id? Is the persistent session backend, frontend or both? – Question Overflow Oct 31 '14 at 2:01
2

An application should rely upon the platform's session handler. Rolling your own session handler is dangerous.

A cookie can be scoped to the parent domain and used by every sub-domain. In PHP this can be done with session_set_cookie_params() to change the scope the domain to *.example.com. Then use session_start() normally.

XSS on any subdomain may compromise the session id. Make sure to enable the Secure and HTTPOnly cookie flags. This will ensure that HTTPS will be used with the session id for all requests, and limit the impact of XSS.

Additionally, generating a session id using the following method is insecure:

$id = md5($userip . $salt .  $userbrowseragent  . $sessionname);

Never attempt to roll your own random number generator. A session id must be a cryptographic nonce generated with a cryptographically secure pseudo-random number generator (CSPRNG). The hash function md5 must never be used in a security context, it has been broken since 2005. Even if a secure hash function were used, the attacker will knows the $userip, $userbrowseragent and the $sessionname, which means they could bruteforce the $salt value offline.

  • Hello, sorry for my delay to check this awnser... saw many examples using .example.com, what is the difference between both? Thanks – LeonanCarvalho Dec 5 '14 at 0:58
  • *.example.com is a scope that encompasses all subdomains of example.com – rook Dec 5 '14 at 1:08

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.