When I have to use Cookie parameter?

[LCF-AT]

Hi guys,

just have a another small question about handling responses and creating new valid request header fields.So recently I found some new issue what did surprise me and I don't understand how to handle it yet.The problem is that there are seems to be some webpages who using other methods to allow cookie requests.Normaly I thought I always HAVE to use the "Cookie: *" field in my requests for any cookie I HAVE to use for another requests reading from "Set-Cookie: X".

Example:

Cookies I got in response...
------------------------------------------------
Set-Cookie: X=12345; path=/; expires=Sat, .... GMT; domain=ABC.com; samesite=none; secure
Set-Cookie: Y=67890; path=/; expires=Sat, .... GMT; domain=ABC.com; samesite=none; secure
Set-Cookie: Z=ABCDE; path=/; expires=Sat, .... GMT; domain=ABC.com; samesite=none; secure
------------------------------------------------

Now I use those 3 cookies into my next request....
------------------------------------------------
Cookie: X=12345; Y=67890; Z=ABCDE
------------------------------------------------
or all as single entrys....

Cookie: X=12345
Cookie: Y=67890
Cookie: Z=ABCDE

So this did worked so far for me but now it dosent work anymore for some pages to send cookie value on that way back.When I check the whole process in network console window then I can see the requests made by browser are looking diffrently and not using the Cooke: paramter field for those entrys.The browser made this...

Cookies I got in response in browser response
------------------------------------------------
Set-Cookie: X=12345; path=/; expires=Sat, .... GMT; domain=ABC.com; samesite=none; secure
Set-Cookie: Y=67890; path=/; expires=Sat, .... GMT; domain=ABC.com; samesite=none; secure
Set-Cookie: Z=ABCDE; path=/; expires=Sat, .... GMT; domain=ABC.com; samesite=none; secure
------------------------------------------------

Browser used those cookies in next request headers so...
------------------------------------------------
X: 12345
Y: 67890
Z: ABCDE

No field used  like Cookie before and also the = sign was removed and now using a :   sign instead.The question is why and how to know that when reading the response header where I got the cookies from?I dont see any entry or info to know that I have to use the cookies like this for my next requests you know.I checked this page...

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

...to find some infos about it but I think there arent any (not sure).Maybe the Cookie prefixes are ment but dont check this yet.

Info: I just forgot to tell one thing.The cookies are used to call a diffrent webpage not the same "ABC.com".So does it mean I can only use the cookies with the "Cookie: *" fields on the s ame domain / sub domains only?Good ok.But when the cookies are also used to call NOT same domain how do I know that I have to use them there too + how do I know that I have to use a colon sign and not using the original cookie entry "X=12345"?Anyhow its getting more and more difficult to handle all those stuff you know.Maybe anyone can tell me how this works correctly to know it for the future.Thank you.

greetz

[whoknows]

1-

cookie can be set only on client side (aka JS).

 

2-

there is no cross domain cookie.

 

3-

possibly what u describe is, that as user u doing a request to a server, once the client (JS), got the response, set some value @ cookie.

 

for server side (aka PHP/ASP) u do the same with session variables.

[whoknows]

+ nowdays, there are all these shits to deal with @

zdnet.com/article/firefox-to-ship-network-partitioning-as-a-new-anti-tracking-defense/

[LCF-AT]

Hi,

still not sure what you mean.The Cookies are set / send by server to me and now I have to check whether I need to use them or not (possibly not all).So apart from this I can read on Wiki this info....

Quote

Domain and path

The Domain and Path attributes define the scope of the cookie. They essentially tell the browser what website the cookie belongs to. For obvious security reasons, cookies can only be set on the current resource's top domain and its sub domains, and not for another domain and its sub domains. For example, the website example.org cannot set a cookie that has a domain of foo.com because this would allow the example.org website to control the cookies of foo.com.

....so when I check that right then the cookie can not be used for other domains but in my example I did post above happens exactly that.I get 3 cookies from Domain A and I must use those 3 cookies for a other domain B (without Cookie: <--- set in header) and using that strange write style in header.If I dont do that then my request does fail and I dont get success status back.Thats the issue I dont check yet you know.I thought there would be a fixed rule as describled above but not in my case.Any kind of trick or something?So before everything was working normaly because just one / same domain was used and I could use the normal way by using "Cookie: *" in my request header but now they chanaged the domain into 2 domains and now I got that strange salad.Hhmm.

greetz

[whoknows]

apart from^, this is where u find all the shits stored

 

a cookie can be used by domain and all of it subdomains .

 

possible, is that SiteA set a cookie and describe it that is for SiteB via 

;domain=domain

//developer.mozilla.org/en-US/docs/Web/API/Document/cookie

 

--

 

Quote

I get 3 cookies from Domain A and I must use those 3 cookies for a other domain

security.stackexchange.com/a/49637

 

--

check localstorage aswell, but again the same rule applied is domain restricted.

--

hope to solve it ASAP!