1

Recently, I started diving into cookies, but as far as the domain property is concerned I don't think it is straightforward.

I read this article:

http://web.archive.org/web/20200418163316/https://www.mxsasha.eu/blog/2014/03/04/definitive-guide-to-cookie-domains/

It points out the recommendation to keep your cookies safe by hosting your websites with a www-prefix, so www.example.com instead of example.com, as in the latter case, IE explorer (or any browser?) will also send the cookies to any (perhaps malicious) subdomain of example.com. But don't you own all the subdomains of a given domain you bought? Why can somebody else own a subdomain under your parent domain in the first place? Aren't you then just setting a cookie for a subdomain someone else owns? That doesn't make sense, does it?

So it is recommended to avoid having untrusted domains under your domain. She also says this is why GitHub pages is hosted under github.io, not github.com, for example. I don't understand why .io would be more secure than .com?

I've learnt that you can always set a cookie for a less specific domain, e.g. bad.example.com can set a cookie for .example.com but not the other way around. What is the ideology behind this from a security perspective? Is this not just dangerous behavior, because a subdomain (which apparently may be owned by someone else?) then can set cookies for all other subdomains of example.com and the parent domain itself? So a user from malicious.example.com gets granted also access to example.com.

When you set a domain value of .example.com, the cookie will be sent to all sub-domains. Does this have anything to do with having the feature of a shared authentication/authorization mechanism that applies to all applications hosted under several subdomains (e.g. dashboard.example.com and admin.example.com) but related to the parent domain/app?

Maybe I'm on the wrong track, but I don't quite understand the WHY behind the specifications.

Improve this question
5
  • .io is not more secure than .com, but it allows user content to be on a completely different domain to avoid the issue altogether.
    – multithr3at3d
    Commented May 16, 2020 at 2:08
  • Aah I got it, but does the same problem not still occur for all the users of the sub domains under .io? So user1.github.io can set a cookie for user2.github.io etc. Or user3.github.io can read cookies from other *.github.io if user3 tricks an user into visiting his page? So you move the problem to another place, accepting the risk it still has for its users, am I right?
    – Maikkeyy
    Commented May 16, 2020 at 7:54
  • no, RFC 6265 says "The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server. For example, 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".
    – multithr3at3d
    Commented May 16, 2020 at 13:07
  • Okayy, so you can't set a cookie for another specific subdomain or a subdomain of your subdomain. But you could still set a cookie for .github.io if you own the subdomain user-1.github.io thus setting a cookie that will be sent to all *.github.io domains., right?
    – Maikkeyy
    Commented May 16, 2020 at 13:21
  • it won't be "sent" to them, but it may be visible if they are checking for a cookie on the root domain. It's only an issue if those subdomains rely on cookies on the root domain, which is already an issue if they are not owned by the same entity.
    – multithr3at3d
    Commented May 16, 2020 at 15:01

1 Answer 1

Reset to default
3

But don't you own all the subdomains of a given domain you bought?

Sure. If you own the domain you control also subdomains. If you have control over applications that use your subdomains, then you can do whatever you want.

But there are hosting providers, that give users subdomains like user-123.provider.com below their own domain. In particular, users don't have to pay explicitly for domain registration. If you as a customer have such subdomain and bind your cookie to a higher level domain name, it can be read and modified by other customers that use this top level domain. To avoid that, you should use more specific domain name.

When you are a provider and need a "root" domain name for your own purposes (advertising, price info, faq, etc.), then again if you bind cookies to the domain name provider.com (I don't discuss here differences between .provider.com and provider.com), all your customers like user-123.provider.com can read and modify your cookies. To avoid this, you should use a more specific domain name like www.provider.com.

Does this have anything to do with having the feature of a shared authentication/authorization mechanism ... ?

Not necessarily. But it can be used for authentication and single-sign-on.

In such case normally all subdomains are controlled by the same owner (company) and different subdomains can be bound to different applications. There is normally a filter that checks if authentication cookie is present. If not present, user is forwarded to the authentication page. When cookie is present, the application at particular subdomain considers user as authenticated. When user navigates to some other subdomain (and thus to other application), the other application will also consider the user as authenticated. Such single-sign-on provides good user experience.

Improve this answer
4
  • This makes it a lot more clear! So if you set a more specific domain AND do want to host user-hosted content, then the only option is to move it to a completely different domain altogether? Because otherwise you would still have the same problem (don't know if you can go lower than .www), correct? Or can you use www.example.com as your main site and next to that use user2.example.com without the .www prefix? Thanks!
    – Maikkeyy
    Commented May 16, 2020 at 8:10
  • 1) It's up to you to use subdomains below www. Technically there is no restriction. 2) If yoiu give subdomains to customers, they should not be below domain you user for your own purposes. Thus they should be directly below TLD, not below www. I.e. they should be user1.example.com, user2.example.com, etc.
    – mentallurg
    Commented May 16, 2020 at 13:35
  • Alright, so technically there is no difference between www.example.com, user1.example and user2.example.com in terms of subdomain characteristics? I always thought that www. was a special preserved subdomain, but apparently it isn't. But user1.example.com can set a cookie with domain value .example.com which then also gets send to www.example.com, or isn't this any kind of a problem because the main site can ignore this cookie?
    – Maikkeyy
    Commented May 16, 2020 at 13:43
  • In such scheme when every subdomain belongs to different customers they should understand that using more generic names like .example.com can lead to problems because other subdomains can read and write such cookies. That's why if one cares about security they will not set cookies to domain levels higher than their subdomain. Thus they will be isolated from the others. Thus neither the the owner of www.example.com nor the owner of user1.example.com will want to set cookies at example.com level.
    – mentallurg
    Commented May 16, 2020 at 13:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .