hi (: I just implemented this pattern http://www.theserverside.com/patterns/thread.tss?thread_id=31258 on top of PHP's in-built session handling functions. I have single sign-on (SSO) and single log-out (SLO) working across several domains. Functionally, I'm very happy with it but I'm concerned about security. So far, I've implemented session ID regeneration on all changes of privileges as well as on fresh sessions. Only the "master" domain ever (re)generates the session ID, passing it on to the slave via a http redirect (if requested). The master will never redirect outside its list of valid slave domains. And if a slave receives a session ID in the query string, it self-redirects to strip it out... so the ID should hopefully stay out of referrer logs. I'm wondering if this is any less secure than just using PHP's in-built session on a single domain? Edit: I should mention this is not SSO across different webapps, it's a single application and userbase that spans several second-level domains. All advice/abuse appreciated! thanks! shy (: http://sla.ckers.org/forum/read.php?4,16753,16753#msg-16753 Thu, 23 May 2013 04:23:21 -0500 Phorum 5.2.15a http://sla.ckers.org/forum/read.php?4,16753,17490#msg-17490 http://sla.ckers.org/forum/read.php?4,16753,17490#msg-17490 erez CSRF and Session Info Sun, 18 Nov 2007 01:12:34 -0600 http://sla.ckers.org/forum/read.php?4,16753,17440#msg-17440 http://sla.ckers.org/forum/read.php?4,16753,17440#msg-17440 serachewhi CSRF and Session Info Thu, 15 Nov 2007 14:27:33 -0600 http://sla.ckers.org/forum/read.php?4,16753,17359#msg-17359 http://sla.ckers.org/forum/read.php?4,16753,17359#msg-17359 -------------------------------------------------------
> I just skim read this, so might be off track...
> why do you need to persist the session via the
> browser based parameters anyway? Use a server
> side or other 'out of band' communication. For
> example, maintain session in a common database
> (you said its the same app, right? )

Hi serachewhi, thanks for your input!

I'm not sure I fully understand what you mean. Would you mind going into more detail?

It is the same app, yep, and sessions *are* stored in the database. The only information being passed through the browser is the session ID itself as would be the case with a "regular" session.

thanks!
shy (:]]> shyguy CSRF and Session Info Mon, 12 Nov 2007 11:14:41 -0600 http://sla.ckers.org/forum/read.php?4,16753,17216#msg-17216 http://sla.ckers.org/forum/read.php?4,16753,17216#msg-17216 serachewhi CSRF and Session Info Tue, 06 Nov 2007 12:33:09 -0600 http://sla.ckers.org/forum/read.php?4,16753,16795#msg-16795 http://sla.ckers.org/forum/read.php?4,16753,16795#msg-16795
it is actually several .com's hence the extra measures, and fortunately it is a single application.. which hopefully means: if there's XSS is one, it's in available on all the other domains anyways.

i think for serious changes i will do as you said and lock it to one host (SSL), and require re-authentication.

the current system is cookie-only PHP sessions without SSL auth.. just wanted to make sure I'm not introducing a huge security hole.. i was a bit iffy about passing the SID in the URL (brief as it may be!)

thank you for your input (:]]> shyguy CSRF and Session Info Tue, 16 Oct 2007 06:27:58 -0500 http://sla.ckers.org/forum/read.php?4,16753,16794#msg-16794 http://sla.ckers.org/forum/read.php?4,16753,16794#msg-16794
All you would need to do would be to set the cookies to .domain.com rather than just domain .com and then the cookies would be sent along with the request for all subdomains.

This can cause further issues with an XSS condition on *any* subdomain being potentially devastating, though that can be mitigated by adding an additional authentication cookies to specific subdomains such as settings.domain.com so that major changes can only occur from that domain, and with those specific cookies.

Having said that, if you envisage some need for SSO across multiple domains, then the method you described is the best method, though I would recommend using a different token for each application, so that an XSS in one application does not lead to the compromise of another.]]> kuza55 CSRF and Session Info Tue, 16 Oct 2007 04:23:06 -0500 http://sla.ckers.org/forum/read.php?4,16753,16793#msg-16793 http://sla.ckers.org/forum/read.php?4,16753,16793#msg-16793
anyway, would love to hear back from some of you

thanks
shy (:]]> shyguy CSRF and Session Info Tue, 16 Oct 2007 03:41:30 -0500 http://sla.ckers.org/forum/read.php?4,16753,16753#msg-16753 http://sla.ckers.org/forum/read.php?4,16753,16753#msg-16753
I just implemented this pattern http://www.theserverside.com/patterns/thread.tss?thread_id=31258 on top of PHP's in-built session handling functions.

I have single sign-on (SSO) and single log-out (SLO) working across several domains. Functionally, I'm very happy with it but I'm concerned about security.

So far, I've implemented session ID regeneration on all changes of privileges as well as on fresh sessions. Only the "master" domain ever (re)generates the session ID, passing it on to the slave via a http redirect (if requested).

The master will never redirect outside its list of valid slave domains. And if a slave receives a session ID in the query string, it self-redirects to strip it out... so the ID should hopefully stay out of referrer logs.

I'm wondering if this is any less secure than just using PHP's in-built session on a single domain?

Edit: I should mention this is not SSO across different webapps, it's a single application and userbase that spans several second-level domains.

All advice/abuse appreciated!

thanks!
shy (:]]> shyguy CSRF and Session Info Sat, 13 Oct 2007 08:10:36 -0500