Programmers usually do not pay much attention to cookies in their web applications except when they use them to store data. Cookies can be a very good attack point for hackers, depending on what is stored in them. Information can be exposed when appropriate scope is not set for cookies.
There is another article here that explains how cookies work. This article will discuss the methods of protecting cookies by limiting their scope.
Whenever a user visits a website, the web browser will look for any cookie that belongs to the website and append it to the request automatically. When a website sets a cookie, it is by default tied to the originating domain. This is called the “same origin policy”. For instance, if server1.cookie-domain.com set the cookie, the web browser will automatically send the cookie with all subsequent requests to that domain and it sub-domains (admin.server1.cookie-domain.com). The cookie will not be sent to the parent domain or peer domains (cookie-domain.com or server2.cookie-domain.com).
This restriction can be over-ridden by a programmer by setting the domain attribute:
Set-cookie: cookie1=somedata; domain=cookie-domain.com;
This will ensure that cookies are sent to top-level domain as well as all sub-domains.
Note: The domain attribute cannot be set to an arbitrary domain. For instance, the application on cookie-domain.com cannot set the domain attribute to say, yahoo.com. If it is set this way, the browser will just ignore the attribute and use the default.
When thinking about security, you need to be aware of the data that is being stored in the cookie as well as the scope of the cookie. There might be another application that has visibility to a particular cookie. If that application has, say, an XSS vulnerability, a hacker might still be able to steal the cookie belonging to the more secure application and abuse it.
Another attribute that cookies have is the path attribute. If an application residing at http://cookie-domain.com/app1/index.jsp sets a cookie, the browser will automatically send this cookie to all requests for pages residing under the /app1/ directory and also any sub-directories. The browser will not include the cookie with request for any other directory on that server, including the parent directory.
This restriction can be over-ridden by a programmer by setting the path attribute:
Set-cookie: cookie1=somedata; path=/app1/
This will ensure that the cookie will only be sent to the application residing at the /app1/ directory and its sub-directories.
Note: If the trailing / is not specified, the browser will send the cookie to all directories that begin with app1. For example, /app1-test/ or /app1-prod/
The security issue that is present in this situation is similar to the domain attribute. If a vulnerable application resides under a directory that also can receive the cookie, a hacker can steal it.
It is important to analyze the scope and visibility of cookies and set the domain and path attributes accordingly. Using the wrong setting or not setting them at all can make your application vulnerable to attacks through applications that reside on other domains or paths that can receive your application’s cookies.