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?

Zhaph - Ben Duguid · Accepted Answer · 2016-09-20T12:18:21.657

15

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.

edited Sep 20 '16 at 12:18

answered Aug 18 '09 at 08:17

Zhaph - Ben Duguid

26,785
5
80
117

I am not an ASP.NET expert, but doesn't it set the cookie 'path' parameter accordingly when using multiple apps under the same domain? – Ferdinand Beyer Aug 18 '09 at 08:21
@Ferdinand Beyer - it might do, but there isn't a "path" or even "domain" attribute on the session state configuration - note that the Forms Auth cookie Path notes say "The default is a slash (/), because most browsers are case-sensitive and will not send cookies back, if there is a path case mismatch.". You're opening yourself to a potential world of pain there. – Zhaph - Ben Duguid Aug 18 '09 at 08:26
The forms authentication cookie name is not the same as the session cookie name (the latter is generally called ASP.NET_SessionId and can be changed independently of the forms/login cookie name) – David Roberts Sep 17 '16 at 16:06
@DavidRoberts hence my "See also" comment - the documentation for the forms auth cookie explains why you might want to rename it, while the session cookie doc's didn't. – Zhaph - Ben Duguid Sep 20 '16 at 12:15
1

But I think that's incredibly misleading to have in the answer. The explanation and rationale are not necessarily applicable because the forms cookie and session cookie are not the same thing. Is there actually any evidence (in the docs) that colliding session cookie names cause the effect described? It does for forms cookie, obviously - but the session [state] cookie? – David Roberts Sep 24 '16 at 11:33
If you are running virtual applications under your main root site, it's possible that the cookies could clash, setting the path can be unreliable as you need to enforce casing and trailing slash behaviour, so having them all set at the root path but with different names will help your apps distinguish between them. This would allow each app to maintain their own session IDs, without impacting on other apps visited by the same user (calling Session.Abandon in one would remove the cookie, clearing the sessionid from all the other apps, which may not be desired). – Zhaph - Ben Duguid Sep 24 '16 at 19:41

score 2 · Answer 2 · answered Aug 18 '09 at 08:05

2

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

answered Aug 18 '09 at 08:05

UpTheCreek

31,444
34
152
221

4

2) may be true, but the first giveaway for ASP.NET will be in the rendered markup and id mangling – Russ Cam Aug 18 '09 at 08:10
Additional giveaways for ASP.NET include the presence of common file extensions such as .aspx, .asmx, .axd; response headers from IIS like x-powered-by: ASP.NET. More subtly, there is the session-locking behavior whereby one session-using request must complete before another may begin. – Larry Silverman Jul 01 '16 at 13:52

score 2 · Answer 3 · answered Nov 25 '15 at 07:11

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”."

score 2 · Answer 4 · answered Oct 02 '19 at 07:15

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.

score 1 · Answer 5 · edited Oct 07 '21 at 07:24

According to the following specification, https://datatracker.ietf.org/doc/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:

Set with a "Secure" attribute

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:

Set with a "Secure" attribute

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

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").

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=/

score 0 · Answer 6 · answered Aug 18 '09 at 08:19

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.

Reason to rename ASP.NET Session Cookie Name?

6 Answers6

Linked