Hi,
Sorry we didn't respond to your initial security messages Nico - I don't actually see anything on the list at that time. Can you check what address you were emailing?
You ideally shouldn't change the session cookie name (from PHPSESSID to something else), as this isn't as secure. Likewise, you should be setting session_store_path to different paths for each site even if they are in sibling directories (rather than parent / child).
Unfortunately we can't do this automatically in SilverStripe - we can't know a safe location to store sessions, as it's server dependant.
However, better than any of this is to have separate domains for each site. No matter what you do on the server side, the web is designed with the domain name being the security context, not the path. Having two separate sites with separate security contexts under the same domain but different paths is a bad idea for lots of reasons, and we can't fix that in code.
--- Technical details start ---
The key to PHP sessions is a large random number. If you have that number, you can access the session.
The server generates this large random number and stores it in it's session store. Then it gives it to the client in a cookie. Because this number is random, no-one else can guess it. Because the traffic is only between client and server (and maybe encrypted, depending on risk profile), no-one else can see it. So that number is only known to a specific client & session store pair, and acts as a shared secret.
However it's important that I said "client" and "session store", not "user" and "website". When the client and the session store are both the same for two different user / website pairs, there's nothing that stops the client from using one shared secret with the other site. They just take the large number from the other site, pretend it's theirs, and the server looks it up, see's it's valid (because it's the same session store), and uses it.
By changing the session_store_path, you give each part of the website different session stores. Then if you try and use the large random number from one site with the other site, it won't find a session.
However you're still open to a lot of other non-session-store based attacks. For instance, because you're on the same domain, pages are allowed to see each other's content when iframed. So a malicious site on the same domain could iframe in the attacked site, and modify the content of the attacked site to perform an action (via an injected form or script). The browser will allow this attack request to use the correct credentials of the attacked site.
In other words, the only secure way to run multiple sites (SilverStripe or anything else) is to run them on separate domains.
A note on SECSESSID - SECSESSID was not really introduced to avoid losing your session, it was to separate the "insecure" session from the "secure" session. It is up to the developer to not do things that rely on strong session guarantees when using the insecure session. For instance, as you mentioned Patrick, it's important to redirect to HTTPS on attempts to log in. HSTS headers would be good here too. We could probably improve how this is warned against (throw an error if you try and store the Member ID in the session while on HTTP).
(It's easy to have environment specific config, both through the configuration system and Director::isLive code checks)