1

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)?

migrated from superuser.com Aug 10 '14 at 13:48

This question came from our site for computer enthusiasts and power users.

2

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.

  • 1
    I don't think the question is about client computers getting compromised, so I'm not sure what your answer is about. He specifically asked about XSS which could be used to steal/set cookies if domains are not setup properly or the cookie is not protected properly. – heavyd Aug 7 '14 at 4:31
  • 1
    @heavyd: XSS attack is about injecting a malicious client-side script. My answer was that once that happens the entire browser is suspect and maybe even the computer, so that the division into sub-domains does not much degrade security, except for domain cookies being a weak spot as maybe somewhat easier to steal. For cookies, my advice was encryption with safeguards such as the IP address included, so to make them unusable from elsewhere (spoofing is still a danger here and may require more defenses). – harrymc Aug 7 '14 at 7:10
  • I wouldn't use IP addresses for cookie validity checking. There are cases where IP addresses change regularly, and in that case embedded IP addresses can disrupt the service. – Tero Kilkanen Aug 10 '14 at 20:25
  • @TeroKilkanen: Login using user/password will renew the cookie in such a case. – harrymc Aug 11 '14 at 6:14
  • Yes, the user can log in again, but depending on the web application, this can cause serious usability issues when the user is suddenly logged out in the middle of his / hers session. – Tero Kilkanen Aug 11 '14 at 12:27
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.