Should I set a domain on cookies and if so why? -
The cookie is used for a shopping basket, the platform is .NET
No, you don't need to. If the cookie header field does not have a domain attribute, the effective domain is the domain of the request.
You will want to set the domain in specific scenarios, if you want to make your www.website.com cookie to be avaliable at api.website.com you will need to set the domain to .website.com.
Also, there is no way to make the www.website.com cookie be avaliable at a different domain by setting its domain (security issue).
Related
I am able to access cookies created locally by using req.cookies or grabbing something specific (req.cookies['myvar']).
Hoever, say a cookie was stored on a top-level domain (domain.com) and then in my subdomain app (my.domain.com) -- how would I grab a cookie value from a certain domain?
The Domain and Path directives define the scope of the cookie: what URLs the cookies should be sent to.
Domain specifies allowed hosts to receive the cookie. If unspecified, it defaults to the host of the current document location, excluding subdomains. If Domain is specified, then subdomains are always included.
For example, if Domain=mozilla.org is set, then cookies are included on subdomains like developer.mozilla.org.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Scope_of_cookies
I have a Koa API which is setting a cookie accessToken which is used by a react front end, running on a different domain.
Because the cookie is set by the API on a different domain, it is considered a third party cookie by the browser which causes issues. Particularly in Safari where it doesn't get saved in the browser by default.
Is there a way I can tell the server to set a cookie with the domain name of the front end so that the front end thinks it's a first party cookie?
I am setting my cookie like so:
ctx.cookies.set("accessToken", accessToken, {
httpOnly: true,
domain: "example.com"
})
If example.com is the front ends domain, should the cookie be interpreted as a first party cookie?
Is this even possible to set a cookie for a different domain?
Thanks
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".
NOTE: For security reasons, many user agents are configured to reject Domain attributes that correspond to "public suffixes". For example, some user agents will reject Domain attributes of "com" or "co.uk". (See Section 5.3 for more information.)
But the above mentioned workaround with image/iframe works, though it's not recommended due to its insecurity.
See RFC6265
I have a website that will have customers logging into:
www.example.com/login
and will do their authenticated tasks here
www.example.com/dashboard/
Customers will also have their own public facing content here:
customer1.example.com
The public facing content is where they can't write their own content, so I am concerned if they write some javascript etc. to grab cookie information somehow i.e. they write javascript, and when a different user goes to their site who was authenticated on www.example.com, the javascript will grab their session cookie and send it over to another website.
When cookies are stored at the root domain and sub-domain, are they free accessible at each level?
Trying to understand the security implications.
Cookies will be accessible for all subdomains of the host you specify in the Domain attribute.
If you set Domain=example.com, the cookies will be available to all subdomains of example.com.
A cookie with Domain=www.example.com will only be accessible for www.example.com and subdomains of www.example.com (e.g. foo.bar.www.example.com) - no worries if you do that.
However, note that this also means it won't be accessible from example.com.
The most restrictive option is to omit the Domain attribute, by not sending it at all. In that case, the cookie should only be accessible for the hostname that sent it. That is, if you send it from www.example.com, it will only be sent back to www.example.com and not even to its subdomains.
This is all explained in RFC 6265, section 4.1.2.3.
anybody know is possible to use Persona for SSO purposes for cross site login which are sub domains of the single domain ? I do no find this useful feature in documentation.
thanks.
If all of the services are within a single domain (e.g. service1.example.com, service2.example.com, etc.), you could set a cookie on the top-level domain directly (example.com) and then all services could use the same session since they would all have access to that session cookie.
So one way to do this would be to redirect users to login.example.com when they click the login button on any of the other sites (service*.example.com). That login service would use Persona to ask the user to login and then it would set a cookie on example.com.
This strategy is of course not specific to Persona, it's a common way to get SSO between internal services within a company for example.
I have a website that came with a SSL site for HTTPS but its on a different server. Example being
my website:
http://example.com
my SSL site:
https://myhostingcompany.com/~myuseraccount/
So I can do transactions over HTTPS and we have user accounts and everything but it is located on a different domain. The cookie domain is set for that one.
Is there a way I can check on my actual site to see if a cookie is set for the other one? And possibly grab its data and auth a user?
I think this violates a major principle of security and can't be done for good reasons, but am i wrong? is this possible?
You can setup a service on either site to handle RPC via HTTP POST requests. You can make it require some sort of session that can only be created by your sites. However, whatever can be accessed over that shared session on the HTTPS site will have no guarantee of confidentiality or integrity.