2

I want to know if it's dangerous in any way to store the current logged user session id on the page generated source code.

Why I wanted to do that?

I'm trying to share the user session between two applications, one (the main) in PHP and another in Node.js. The Node.js one is used just for real-time data, but I just want to send live data to logged in users in the PHP application.

As the session ids are stored in a Redis instance accessible for both PHP and Node, I can just send the session id from the client to the Node.js (using websockets messaging).

Why not use the cookies already present in the user browser?

The Node application is served using a different host. So the cookie is not going to be available.

Improve this question
2
  • You can bind a cookie to a specific path /php, and /node_js. So you can still use the Secure and HTTPOnly cookie directives, and have a secure session handler.
    – rook
    Jan 30, 2014 at 18:48
  • @Rook they are on different domains
    – jonathancardoso
    Jan 30, 2014 at 19:11

4 Answers 4

Reset to default
3

YES there is a risk introduced by including the session identifier the HTML code as it will make it easier to exploit XSS vulnerabilities to hijack sessions.

First, accessing session id from JavaScript is BAD PRACTICE, cookies should have the HTTPONLY flag to prevent that.

In your case, even if the HTTPONLY flag is set, having the session identifier in page body makes it easier to access this identifier while exploiting the XSS and thus bypass the HTTPONLY.

Improve this answer
6
  • If there is holes to execute XSS, the security is already compromised, and the session hijack is just more weight to the balance.
    – jonathancardoso
    Jan 30, 2014 at 0:34
  • You are correct, exploiting the session id requires an already vulnerable application. Good security is however based on layered defense. If the application suffers from an XSS (which is a very common vulnerability in web applications) it should have measures in place to prevent easy exploitation of the vulnerability. Your question was if there is an extra risk with such implementation, it is however up to you to assess the risk and determine if it is acceptable.
    – 3asm_
    Jan 30, 2014 at 0:48
  • Thank you for the introduction to layered defense. Do you have any suggestions on how what I want could be implemented without relying directly on the session id?
    – jonathancardoso
    Jan 30, 2014 at 1:05
  • 1
    If the goal is to share resources between two different applications on two different domains I believe Cross-origin resource sharing (CORS) might help. It has been introduced with HTML5. I think this entry on stack overflow discusses the subject in more details stackoverflow.com/questions/2870371/…
    – 3asm_
    Jan 30, 2014 at 1:17
  • +1 You cant use HTTPONly if you write the session id to the page. If the session id is in the URL you will print it out to paper if you print one of the pages!
    – rook
    Jan 30, 2014 at 18:49
1

As long as your code is bug free and not susceptible to session fixation or XSS and is accessed via HTTPS with secure cookies then its probably OK - but that is a very tall order to achieve and maintain. When it does break it will be really hard to detect/test/fix any problems. The solution you propose is very fragile.

The best solution for sharing a session across different application stacks is to provide access to them via the same vhost - that way there's no messing about with messaging to handle the cookie problem - there are very good and stable products available for doing this - many of which are free (Varnish, Nginx, Apache Traffic server).

Alternatively it should be possible to reproduce a SSO type architecture to share the session across different vhosts.

Improve this answer
2
  • I guess you have never heard of "defense in depth."
    – rook
    Jan 30, 2014 at 18:47
  • Given that I explained why the proposed method was unsafe, I can only assume you refer to the other 2 approaches I recommend - can you explain why these undermine the principle of defence in depth?
    – symcbean
    Jan 31, 2014 at 18:52
0

Are you using HTTPS for responses from both hosts? If so, there is no particular danger. If not, you've just extended the potential for session hijacking that already existed for you PHP and Node hosts independently (because of the session cookies) across all the requests for both your PHP and Node hosts.

As long as you use SSL, you're relatively safe here. If you aren't using SSL, and there is sensitive data at stake, you aren't.

Improve this answer
1
  • Nice to hear. SSL is not used on dev machines, but will be used to serve every request on the production server.
    – jonathancardoso
    Jan 29, 2014 at 22:20
0

You should probably try an ajax request from your php code to refresh your client on live data being sent to your common server. This keeps all concerns separate, and doesn't needlessly create a requirement that your php code be tied down to one source.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .