Cookie security risk between primary domain and a CMS on a subdomain

Question

Without making the question too general, I am looking to discover the specific risks associated with cookies between my primary domain hosting HTML content only, to a subdomain that is hosting Hubspot, a Web-based CMS.

Consider I have the following sites:

//Main site - uses HTML only, no server side languages for security
example.com

//Uses Hubspot and has Hubspot associated cookies, PHP etc. 
downloads.example.com

//Our central order processing and management system (the key asset) - uses various server-side technologies e.g. Java
internal.example.com

What I'm looking to discover is if we need to host the Hubspot site elsewhere, or if it safe to host it at downloads.example.com, without creating security implications for internal.example.com.

Specifically, the kind of risks I have been looking at are:

• XSS attack on downloads.example.com could create a malicious cookie, shared with internal.example.com
• Download files on downloads.example.com could be altered by a hacker to contain damaging viruses and programs.

So the question is, does the Hubspot site at downloads.example.com, create vulnerabilities for the other sites (even all servers are hosted separately)?

Answer 1

To my way of thinking, if the client's browser is compromised then everything is possible. Or in other words : Whether a website is a sub-domain or not does not matter much to security.

In any case, if the websites are defined as sub-domains then you should avoid cookies that are defined for the upper-level domain - define the cookies for downloads.example.com or internal.example.com rather than for example.com.

Once a client has been compromised, one has to assume that all browser data is accessible and modifiable by the malicious software that is running on the client, either in the browser sandbox or even outside it if a more serious infection has occurred.

The dangers I can see once a browser has been compromised are :

1. Cookies stealing.
   This might make it possible for an outsider to steal the identity of your client. You could guard against this by encrypting your cookies and by associating and checking the IP address of the client against the cookie as well as its period of validity.

2. Cookies modification.
   Existing cookies might be modified, but it's quite hard to imagine a use for it.

3. Malicious files.
   If the client logs into an FTP server and transmits file to a general pool, such files could be modified and malicious code inserted, even into image files or pdf. If your clients use Java, then an applet which gains write access to the local disk may seriously infect the local computer. If the applet gains such access to the network, it may do the same to all files located in network shares.

In conclusion: You should concentrate on protecting the client computers that access your websites. The web-servers should of course be hardened as much as possible, and especially login information should never be stored in clear-text cookies. Try to limit network access in-between servers to avoid the spread of infections using external and internal firewalls. Java should be avoided as much as possible and replaced by HTML5 if possible. You should also practice some serious paranoid thinking.

Answer 2

you will not have security risks with these cookies if you set them as http only cookies via ssl connection. This means they are set with the http only flag and then set on a page which is ssl secure.

if you have hhtp only flags and secure flags you should be fine.

if you want to take it a step further consider using a engrypted key as the cookie and then pull all real values from a db table linked to that cookie. you can check to see if ip address matches the hash as a foolproof way to prevent cookie jacking. can be made even mor secure by checking against more than ip, but also browser signature such as os, fonts, etc. again overkill unless if your building a banking app.