Re:The CNAME of the Game: Large-scale Analysis of DNS-based ...
by tinus_hn on Thursday March 04, 2021 @07:16PM
(#26350499)
This doesn’t work because browsers only see the original domain names. A page loaded from awesome.example.org can only set cookies on awesome.example.org and on example.org and not on evil.com, no matter what CNAME tricks you pull.
[ Parent
| on HN ]
Re:The CNAME of the Game: Large-scale Analysis of DNS-based ...
by fluidcruft on Thursday March 04, 2021 @07:26PM
(#26350609)
What's said is that query on CNAME returns the resolved address of evil.com, not "evil.com" as a name that needs to be further resolved.
Isn't cookie validity selected by the site? A diligent site could setup subdomains to isolate the tracking cookines. Say, .awesome.example.org rather than .example.org. tracking-you.example.org wouldn't match anymore. But then it's a third-party cookie again and ad-block could just keep cookie whitelists for .awesome.example.org and throw any other .example.org cookies out.
Re:The CNAME of the Game: Large-scale Analysis of DNS-based ...
by tinus_hn on Friday March 05, 2021 @05:13AM
(#26355104)
It doesn’t work like this. Cookie domains, like cookie paths, are not a security feature because scripts in documents can manipulate other documents that are considered by the browser to have the same origin. A site can’t change the origin rules, the origin for both ‘awesome.example.org’ and ‘tracking-you.example.org’ both is example.org .
Re:The CNAME of the Game: Large-scale Analysis of DNS-based ...
by fluidcruft on Friday March 05, 2021 @10:26AM
(#26357834)
Yeah, exactly. awesome.example.org is the example.org site's code and tracking-you.example.org is evil.com's code.