Understanding cookie domain relationship with top level domain and its subdomains

I have a domain with 2 subdomains like this: www.domain.com and secure.domain.com (with ssl). www subdomain will be running vbulletin (prone to xss attacks) and the webservice behind secure subdomain is well, more secure as well as more sensitive to attacks since real money is involved there. domain.com is 301 redirecting to www.domain.com. Now I'd like to have a single sign-on to both of the services without compromising the security of the secure subdomain. It seems to me there are 2 ways of doing this:

1. Using OpenI开发者_Python百科D and after successful authentication, set cookie domain only to subdomains respectively, example .www.domain.com and .secure.domain.com so that secure.domain.com cookies will not be sent to the attacker in case of an intrusion in www.domain.com

2. Only enable users to log on from secure.domain.com and set 2 cookies, 1 with .domain.com for seamless authentication to www.domain.com and another cookie to .secure.domain.com to verify that the user has authenticated through secure subdomain.

My understanding is that when it comes to sso across several webapps on a single domain and its subdomains, then running any app on top level domain such as domain.com would be a potential security risk because the app on top level will always be sent all the cookies set by subdomains as well as subdomains will be able to set and receive cookies of the top level domain.

The question is this: Are my assumptions correct or did I miss something?

You can set the cookie as secure and it will be sent only over SSL connections (no matter what domain the client connects to). Of course, more complicated scenarios are possible as well.