: Cookie security risk between primary domain and a CMS on a subdomain Without making the question too general, I am looking to discover the specific risks associated with cookies between my primary

@Samaraweera270

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.

Vote Up Vote Down

@Yeniel560

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 :


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.
Cookies modification.
Existing cookies might be modified, but it's quite hard to imagine a use for it.
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.

Vote Up Vote Down