Reason to rename ASP.NET Session Cookie Name?

Question

is there any reason (safety?) why someone should rename the ASP.NET Session Cookie Name or is it just a senseless option of ASP.NET?

Answer 1

If you have several applications running under the same domain on the same server, you may well want to have seperate session cookie names for each one, so that they aren't sharing the same session state or worse still overwriting each other.

See also the notes for the Forms Auth cookie name:

Specifies the HTTP cookie to use for authentication. If multiple applications are running on a single server and each application requires a unique cookie, you must configure the cookie name in each Web.config file for each application.

Answer 2

I think its mainly a matter of taste. Some people/companies want control every aspect of their web apps and might just use another name for consistency with other cookie names. For example, if you use very short one-character parameter names throughout your app you might not like session cookie names like ASPSESSID.

Security reasons might apply but security through obscurity is rather weak in my opinion.

Answer 3

According to the following specification, https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00, that modern browsers implement, the prefixes are used to make things more secure.

3.1. The "__Secure-" prefix

If a cookie's name begins with "__Secure-", the cookie MUST be:

1. Set with a "Secure" attribute

2. Set from a URI whose "scheme" is considered "secure" by the user agent.

   The following cookie would be rejected when set from any origin, as the "Secure" flag is not set

   Set-Cookie: __Secure-SID=12345; Domain=example.com

   While the following would be accepted if set from a secure origin
   (e.g. "https://example.com/"), and rejected otherwise:

   Set-Cookie: __Secure-SID=12345; Secure; Domain=example.com

3.2. The "__Host-" prefix

If a cookie's name begins with "__Host-", the cookie MUST be:

1. Set with a "Secure" attribute
2. Set from a URI whose "scheme" is considered "secure" by the user agent.
3. Sent only to the host which set the cookie. That is, a cookie named "__Host-cookie1" set from "https://example.com" MUST NOT contain a "Domain" attribute (and will therefore be sent only to "example.com", and not to "subdomain.example.com").

4. Sent to every request for a host. That is, a cookie named "__Host-cookie1" MUST contain a "Path" attribute with a value of "/".

   The following cookies would always be rejected:

   Set-Cookie: __Host-SID=12345 Set-Cookie: __Host-SID=12345; Secure Set-Cookie: __Host-SID=12345; Domain=example.com
   Set-Cookie: __Host-SID=12345; Domain=example.com; Path=/
   Set-Cookie: __Host-SID=12345; Secure; Domain=example.com; Path=/

Answer 4

With cookie prefixes, you can add a security attribute to your cookie by naming it a special way. So in that case renaming your ASP.NET session cookie does have an impact on security:

• __Secure-… cookies can only be written from secure (HTTPS) sites.
• __Host-… cookies can only be written from the same, secure domain. So not from subdomains or insecure (HTTP) sites.

Answer 5

Below link provides more information about why session cookies should be renamed.

https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

"The name used by the session ID should not be extremely descriptive nor offer unnecessary details about the purpose and meaning of the ID.

The session ID names used by the most common web application development frameworks can be easily fingerprinted [0], such as PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET), etc. Therefore, the session ID name can disclose the technologies and programming languages used by the web application.

It is recommended to change the default session ID name of the web development framework to a generic name, such as “id”."

Answer 6

1) It might (slightly) slow someone down who is (casually) looking for it.

2) You might want to hide the fact that you are running ASP.NET