Liberal Cookie Scope
The usual simple summary of how cookies work is that the server issues a cookie using the HTTP response header Set-cookie , and the browser then resubmits this cookie in subsequent requests to the same server using the Cookie header. In fact, matters are rather more subtle than this. The cookie mechanism allows a server to specify both the domain and the URL path to which each cookie will be resubmitted. To do this, it uses the domain and path attributes that may be included in the Set-cookie instruction.
Cookie Domain Restrictions
When the application residing at foo.wahh-app.com sets a cookie, the browser will by default resubmit the cookie in all subsequent requests to foo.wahh-app.com , and also to any subdomains, such as admin.foo.wahh-app.com . It will not submit the cookie to any other domains, including the parent domain wahh-app.com and any other subdomains of the parent, such as bar.wahh-app.com .
A server can override this default behavior by including a domain attribute in the Set-cookie instruction. For example, suppose that the application at foo.wahh-app.com returns the following HTTP header:
Set-cookie: sessionId=19284710; domain=wahh-app.com;
The browser will then resubmit this cookie to all subdomains of wahh-app.com , including bar.wahh-app.com .
If an application sets a cookie’s domain scope as unduly liberal, this may expose the application to various security vulnerabilities.
For example, consider a blogging application that allows users to register, log in, write blog posts, and read other people’s blogs. The main application is located at the domain wahh-blogs.com , and when users log in to the application they receive a session token in a cookie that is scoped to this domain. Each user is able to create blogs that are accessed via a new subdomain which is prefixed by their username, for example:
“herman.wahh-blogs.com“
“solero.wahh-blogs.com“
Because cookies are automatically resubmitted to every subdomain within their scope, when a user who is logged in browses the blogs of other users, their session token will be submitted with their requests. If blog authors are permitted to place arbitrary JavaScript within their own blogs (as is usually the case in real-world blog applications), then a malicious blogger will be able to steal the session tokens of other users in the same way as is done in a stored cross-site scripting attack.
The problem arises because user-authored blogs are created as subdomains of the main application that handles authentication and session management. There is no facility within HTTP cookies for the application to prevent cookies issued by the main domain from being resubmitted to its subdomains. The solution is to use a different domain name for the main application (for example, www.wahh-blogs.com ), and scope the domain of its session token cookies to this fully qualified name. The session cookie will not then be submitted when a logged-in user browses the blogs of other users.
A different version of this vulnerability arises when an application explicitly sets the domain scope of its cookies to a parent domain. For example, suppose that a security-critical application is located at the domain sensitiveapp.wahh-organization.com . When it sets cookies, it explicitly liberalizes their domain scope, as follows:
Set-cookie: sessionId=12df098ad809a5219; domain=wahh-organization.com
The consequence of this is that the sensitive application’s session token cookies will be submitted when a user visits every subdomain used by wahh-organization.com , including:
” www.wahh-organization.com ”
” testapp.wahh-organization.com “
Although these other applications may all belong to the same organization as the sensitive application, it is undesirable for the sensitive application’s cookies to be submitted to other applications, for several reasons:
■ The personnel responsible for the other applications may have a different level of trust than those responsible for the sensitive application.
■ The other applications may contain functionality which enables third parties to obtain the value of cookies submitted to the application, as in the previous blogging example.
■ The other applications may not have been subjected to the same security standards or testing as the sensitive application (e.g., because they are less important, do not handle sensitive data, or have been created only for test purposes). Many kinds of vulnerability that may exist in those applications (for example, cross-site scripting vulnerabilities) may be irrelevant to the security posture of those applications but could enable an external attacker to leverage an insecure application in order to capture session tokens created by the sensitive application.
Cookie Path Restrictions
When the application residing at /apps/secure/foo-app/index.jsp sets a cookie, the browser will by default resubmit the cookie in all subsequent requests to the path /apps/secure/foo-app/ , and also to any subdirectories. It will not submit the cookie to the parent directory or to any other directory paths that exist on the server.
As with domain-based restrictions on cookie scope, a server can override this default behavior by including a path attribute in the Set-cookie instruction. For example, if the application returns the following HTTP header:
Set-cookie: sessionId=187ab023e09c00a881a; path=/apps/;
the browser will then resubmit this cookie to all subdirectories of the /apps/path.
It is surprisingly common to encounter applications that explicitly liberalize the path scope of their cookies to the web server root ( / ). In this situation, the application’s cookies will be submitted to every application accessible via the same domain name. For example:
/apps/secure/bar-app/
/apps/test/
/blogs/users/solero/
Liberalizing a cookie’s path scope can leave an application vulnerable in the same way as when an application sets the domain scope of a cookie to its parent domain. If a security-critical application sets a cookie with its path scope set to the web server root, and a less secure application resides at some other path, then the cookies issued by the former application will be submitted to the latter. This will enable an attacker to leverage any weakness in the less secure application as a means of attacking sessions on the more secure target.
NEXT is..Securing Session Management.,.,.,.,..,.,,.,.
