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?
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.
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
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”."
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.
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=/
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.
Related
I'm working on making a Symfony website secure. I have taken a look at this page: How to set secure and httponly attributes on Symfony 4 session
and applied the suggested change into framework.yaml:
session:
handler_id: ~
cookie_secure: true
cookie_httponly: true
When I log in, in the network tab I see three instances of Set-Cookie. The first is a cookie removal, having secure and HttpOnly attributes. The second is a cookie creation, where the cookie identifier has the secure and HttpOnly attributes. The third is setting some parameters in an HTTP-encoded manner, this one also has the secure and HttpOnly attributes. So far so good. However, when I go to any page, I have a Cookie attribute among the Request Headers which has the same identifier as the one which was created earlier, but the secure and HttpOnly attributes are not specified.
So, when I log in and the cookie is created I have the attributes I expect, but later, on visiting separate pages I no longer see them. Why is the secure and HttpOnly attribute not specified on later, after-login Request Headers? Did I miss something?
The security attributes are set by the server in the Response headers and the browser uses them to determine if it has to send the cookie along in the Request, but it never sends the attributes themselves, just the cookie value. If you inspect an ajax or unsecure request the cookie header should not appear in the request at all.
You can see some examples in the RFC6265.
RFC 6265 states that a user-agent should proceed in the following way when receiving a Set-Cookie header:
If the Domain attribute is set:
Set the cookie's domain to the domain-attribute.
Set the cookie's host-only-flag to false.
If the Domain attribute is not set:
Set the cookie's domain to the canonicalized request-host.
Set the cookie's host-only-flag to true.
This is all clear. The confusion comes with this paragraph:
If the user agent receives a new cookie with the same cookie-name,
domain-value, and path-value as a cookie that it has already stored,
the existing cookie is evicted and replaced with the new cookie.
Let's take an example, with two cookies received on the domain www.example.com:
Set-cookie: name=value
Set-Cookie: name=value; Domain=www.example.com
The domain (and path) will be the same for both cookies, but the first one will have the host-only-flag set to true, and the second one to false.
Reading the RFC, it looks like it doesn't matter when comparing the two cookies, and they should be considered equivalent anyway, but I'm not sure my interpretation is correct.
Should the user-agent replace the first cookie with the second one, or should it store both of them?
The paragraph that confuses you is about the ability to assign a new value to a cookie (as well as changing/refreshing the cookie expiration date). If it were not written that way, the HTTP client would need to store multiple cookies with the same name could and it would need to decide on another criterium which to send to the HTTP server upon the next request.
Regarding the second part of your question:
If those two cookies are specified within the same request, the second one "wins", therefore a cookie with the host-only-flag = false would be stored.
If those two cookies come in separate requests, the second one overwrites the first one, because they match in cookie-name (specified), domain-value (once specified, once derived), and path-value (derived). When storing them, the entries in the browser's cookie database only differ in the host-only-flag.
This host-only-flag comes into effect when the client issues a new request to the server (snippet from RFC6265):
The user agent MUST use an algorithm equivalent to the following
algorithm to compute the "cookie-string" from a cookie store and a
request-uri:
1. Let cookie-list be the set of cookies from the cookie store that
meets all of the following requirements:
* Either:
The cookie's host-only-flag is true and the canonicalized
request-host is identical to the cookie's domain.
Or:
The cookie's host-only-flag is false and the canonicalized
request-host domain-matches the cookie's domain.
The fine detail is in how the domain is compared. The matching algorithm is specified in section 5.1.3.
Essentially you can have a cookie be valid for all subdomains if the domain is specified with a leading "."
When the domain is omitted, though, (and therefore implied by the server from the request), this can never be the case because there always needs to be an identical match in the domain.
Further research determined:
In practice browsers store a domain that has been specified in the cookie with a prepended . (for www.example.com it will store .www.example.com) so that a request to subdomain.www.example.com will also return that cookie. When no domain is specified the plain domain without a prepended . will be stored, thus a request to a subdomain will not include that cookie.
I looked in many questions about cookies but I didn't find an answer on my problem. I have following scenario:
A user creates a login on example.com and should get a cookie but only for the subdomain fuu.example.com. I generate following HTTP header part:
Set-Cookie: name=TestUser; Domain=fuu.example.com; Path=/; secure; HttpOnly
But when I make a request to https://fuu.example.com, the cookie will be not added to the request. I wonder if it is possible that example.com sets a cookie for fuu.example.com. I know that it is possible that example.com set a cookie for .example.com also for all subdomains for example.com but that's not what I want.
How do I set a cookie for a subdomain? I am not seeing the cookie in a request to the subdomain.
No. Besides that fuu.example.com is an invalid Domain value (it must start with a ., i.e. .fuu.example.com) (see update below) the cookie would get rejected:
To prevent possible security or privacy violations, a user agent rejects a cookie (shall not store its information) if any of the following is true:
The request-host is a Fully-Qualifed Domain Name (not IP address) and has the form HD, where D is the value of the Domain attribute, and H is a string that contains one or more dots.
The request-host is example.com and the Domain attribute value is foo.example.com. But the request-host example.com does not has the form HD where D would be foo.example.com. Thus the cookie gets rejected.
Update The current specification RFC 6265, that obsoleted RFC 2109 that is quoted above, does ignore the leading dot. But the effective domain is handled the same:
[…] if the value of the Domain attribute is
"example.com", the user agent will include the cookie in the Cookie
header when making HTTP requests to example.com, www.example.com, and
www.corp.example.com. (Note that a leading %x2E ("."), if present,
is ignored even though that character is not permitted, but a
trailing %x2E ("."), if present, will cause the user agent to ignore
the attribute.)
[…] the user agent will accept a cookie with a
Domain attribute of "example.com" or of "foo.example.com" from
foo.example.com, but the user agent will not accept a cookie with a
Domain attribute of "bar.example.com" or of "baz.foo.example.com".
The 2 domains example.com and foo.example.com can only share cookies if the domain is explicitly named in the Set-Cookie header. Otherwise, the scope of the cookie is restricted to the request host.
For instance, if you sent the following header from foo.example.com:
Set-Cookie: name=value
Then the cookie won't be sent for requests to example.com. However if you use the following, it will be usable on both domains:
Set-Cookie: name=value; domain=example.com
In RFC 2109, a domain without a leading dot meant that it could not be used on subdomains, and only a leading dot (.example.com) would allow it to be used across subdomains.
However, modern browsers respect the newer specification RFC 6265, and will ignore any leading dot, meaning you can use the cookie on subdomains as well as the top-level domain.
In summary, if you set a cookie like the second example above from example.com, it would be accessible by foo.example.com, and vice versa.
For more details : https://stackoverflow.com/a/23086139/5466401
Actually, there is a simple and fully cross-browser support way for sharing cookies between original domain and subdomains but you should share it in setting time, for comfortable working with cookie stuffs in browser I'm using js-cookie and with the below setting cookie it could be shared between original domain and all of its subdomains:
Cookie.set('key', 'value', { domain: '.domain.com' })
// a . added before domain name
Hint: Adding this . will share cookie with all sub-subdomain.
I'm writing a small class that acts as a very basic HTTP client. As part of a project I'm working on, I'm making it cookie aware. However, it's unclear to me what happens when my client receives multiple "Set-Cookie" headers with the same key but different values are set.
For example,
Set-Cookie: PHPSESSID=abc; path=/
Set-Cookie: PHPSESSID=def; path=/
Set-Cookie: PHPSESSID=ghi; path=/
Which one of these is supposed to be the value for PHPSESSID? This usually ends up happening when you call session_start() and then session_regenerate_id() on the same page. Each will set its own header. All browsers seem to do okay with this, but I can't seem to get my client to pick the right one out.
Any ideas?!
RFC 6265 section 4.1.2 states:
If the user agent receives a new cookie with the same cookie-name,
domain-value, and path-value as a cookie that it has already stored,
the existing cookie is evicted and replaced with the new cookie.
Notice that servers can delete cookies by sending the user agent a
new cookie with an Expires attribute with a value in the past.
So I would process the headers in order given and overwrite them if there is a duplicate. So in your case you would have just one PHPSESSID=ghi.
RFC 6265 states:
Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name.
I would therefore be very concerned if your service sends multiple Set-Cookie headers with the same key. Especially because I have seen user agents and proxies behave unexpectedly - sometimes taking the value of the first header, sometimes rearranging headers.
As a client, the typical user agent behavior seems to be to take the value of the last header. The RFC alludes to that behavior with this statement:
If the user agent receives a new cookie with the same cookie-name, domain-value, and path-value as a cookie that it has already stored, the existing cookie is evicted and replaced with the new cookie.
Since session and cookies are both used to store temporary data, what is the difference between them?
As for may knowledge:
If you set the variable to "cookies", then your users will not have to log in each time they enter your community.
The cookie will stay in place within the user’s browser until it is deleted by the user.
But Sessions are popularly used, as the there is a chance of your cookies getting blocked if the user browser security setting is set high.
If you set the variable to "sessions", then user activity will be tracked using browser sessions, and your users will have to log in each time they re-open their browser. Additionally, if you are using the "sessions" variable, you need to secure the "sessions" directory, either by placing it above the web root or by requesting that your web host make it a non-browsable directory.
The Key difference would be cookies are stored in your hard disk whereas a session aren't stored in your hard disk. Sessions are basically like tokens, which are generated at authentication. A session is available as long as the browser is opened.
hope following links will further clarifying your doubts
http://wiki.answers.com/Q/What_is_the_difference_between_session_and_cookies
http://www.allinterview.com/showanswers/74177.html
Cookies store a user's data on their computer.
Session implementations store a user's temporary data on a server (or multiple servers, depending on the configuration).
In each HTTP response, the server has the opportunity to add a header Set-Cookie: {cookie-name}={cookie-data}; {cookie-options}.
The browser will, in every subsequent HTTP request (or as specified by the options), add a header Cookie: {cookie-name}={cookie-data}.
Request #1:
POST /auth/login HTTP/1.1
Host: www.example.com
username=Justice&password=pass1234
Response #1:
HTTP/1.1 307 Temporary Redirect
Set-Cookie: user_id=928
Location: http://www.example.com/dashboard
Request #2:
GET /dashboard HTTP/1.1
Host: www.example.com
Cookie: user_id=928
Response #2:
HTTP/1.1 200 OK
Content-Type: text/html
<html>
<head>...</head>
<body>...</body>
</html>
All future requests will also include the Cookie header.
Cookies are stored on the client as either small text files on the files system (persistent cookies) or in the browsers memory (non-persistent cookies) and passed to the server and returned to the client with each request and response. Persistent cookies will still be available between browser sessions as long as the expiry date has not passed. Non-persistent cookies will be lost once the browser is closed.
Session is stored on the server in memory. Cookies are very often used as a way of preserving the reference to the users session between requests however this can also be done with querystring parameters if cookies are disabled on a clients browser.
A cookie is client side a session is server side
Sessions are stored server side. You can have inproc sessions, which will be stored in memory, or you can store the sessions in an SQL database. You can read more here.
Cookies are stored on the client's computer. This means that it's not recommended to store important details in a cookie, because clients could easily manipulate them.
Cookies are a small text file stored on the client that can hold domain specific information,
a session is held server side in either memory, a database or a seperate server and keyed via a session key, they are meant only to persist for a 'session' where as a cookie can persist for a length of time or indefinately therefore being usable in multiple sessions.
They are not the same thing. A Session is a concept whereby the state of a single user's browsing session is stored.
Cookies are a good means of implementing this concept, thus the widespread practice of "Session cookies".
The main difference between data stored in session and cookies is that data stored in session is stored on the server side (user can't operate on such data), while cookies are stored on a client side. They might be manipulated somehow by user. If you have a really sensitive data - then store it in session. But all other data you can store in cookies not to overload the server.