4 ms·

Based on reading the links someone posted, my understanding is that the way this CNAME stuff works is: 1. awesome.example.org would add a CNAME record that res

Based on reading the links someone posted, my understanding is that the way this CNAME stuff works is: 1. awesome.example.org would add a CNAME record that resolves tracking-you.example.org to the server referenced by evil.com 2. awesome.other.net would add a CNAME record that resolves tracking-you.other.net to the server referenced by evil.com 3. etc everywhere on the internet Because these are CNAME, DNS hides all of this from the browser and it just sees the resolved address and the original requested name. So tracking-you.example.org and tracking-you.other.net both now think the server controlled by evil.com is first-party. evil.com now gets all the first-party cookies. In the past they would have only got third-party cookies and the first-party cookies wouldn't be seen by evil.com. But it gets worse because evil.com is also tracking you (it's what they're explicitly doing) so they can link users across the sites. This means evil.com has all it needs to spoof you cross-site because they now have all the first-party auth tokens. Unless you diligently never use the sites simultaneously and remember to log out between using websites. But even if you did, they can still do anything they want as you while you're logged in to the site. So, yeah. It actually looks like a disaster and we're super screwed.

thrwwy0304 6y ago
Your example is reliant on UserA visiting example.com having the same "auth token" as UserA visiting other.net. That's not the case. Both example.com and other.net are likely to be generating completely unique auth tokens. example.org and other.net can certainly both coordinate with evil.com to manually share more detail (e.g. the current user is UserA@gmail.com), but if that's the threat then browsers have no chance at offering protection.
- fluidcruft 6y ago
  No, it's not reliant on that at all. The CNAME trick means that the browser forwards each site's auth tokens directly to evil.com's servers whenever you use that site. And since evil.com's entire reason d'etre is to track you across sites, it's trivial for them to store and link your auth tokens from all the sites you visit.
  - thrwwy0304 6y ago
    When evil.com receives an auth token for a user visiting example.org, how does it know which user that token is associated with? Then, when evil.com receives a different auth token for the same user visiting other.net, how does evil.com know that new auth token correlates to the same user on example.org? This is the third-party identity linking that's now impossible for evil.com to accomplish independently. They need other.net and example.org to share some common information (like an email address) to make the link. For logged out users, it should be impossible without resorting to fingerprinting. This was Firefox and Safari's entire reason d'etre for launching Total Cookie Protection and Intelligent Tracking Protection. I don't believe CNAME cloaking overcomes their protections, or at the very least, I don't see where this paper explains an attack vector.
  - tatersolid 6y ago
    Except your auth tokens on the each site should be opaque identifiers and can’t be linked. Unless both sites are using the disaster that is JWT/JOSE as their token format with signing only and not encryption.
    - fluidcruft 6y ago
      The reason sites are adding these CNAME tricks is specifically to enable evil.com to track you across sites to sell ads. So it's not just the CNAME trick, it's specifically what evil.com is doing that links accounts across sites. The bottom line is that evil.com would not be asking sites to install CNAME tricks in their domains if evil.com cannot leverage those tricks to track users across sites. That should be obvious.
  - thrwwy0304 6y ago
    > The bottom line is that evil.com would not be asking sites to install CNAME tricks in their domains if evil.com cannot leverage those tricks to track users across sites. That should be obvious. This is the leap I believe is incorrect. The paper doesn't explain how CNAME cloaking helps evil.com track users across sites. It says that it does, but it doesn't actually explain the attack vector. It is far more plausible to me that CNAME tricks are being added so that evil.com can track a user on an individual site. When uBlock Origin is putting a hard block on all traffic to evil.com, there's still quite a bit to be gained by shifting evil.com to evil.foo.com if that means requests start succeeding again. Another poster said something similar here: https://news.ycombinator.com/item?id=26349987 https://news.ycombinator.com/item?id=26349987
tinus_hn 6y ago
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.
- fluidcruft 6y ago
  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.
  - tinus_hn 6y ago
    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 .
    - fluidcruft 6y ago
      Yeah, exactly. awesome.example.org is the example.org site's code and tracking-you.example.org is evil.com's code.

thrwwy0304 6y ago

Your example is reliant on UserA visiting example.com having the same "auth token" as UserA visiting other.net. That's not the case. Both example.com and other.net are likely to be generating completely unique auth tokens. example.org and other.net can certainly both coordinate with evil.com to manually share more detail (e.g. the current user is UserA@gmail.com), but if that's the threat then browsers have no chance at offering protection.

fluidcruft 6y ago
No, it's not reliant on that at all. The CNAME trick means that the browser forwards each site's auth tokens directly to evil.com's servers whenever you use that site. And since evil.com's entire reason d'etre is to track you across sites, it's trivial for them to store and link your auth tokens from all the sites you visit.
- thrwwy0304 6y ago
  When evil.com receives an auth token for a user visiting example.org, how does it know which user that token is associated with? Then, when evil.com receives a different auth token for the same user visiting other.net, how does evil.com know that new auth token correlates to the same user on example.org? This is the third-party identity linking that's now impossible for evil.com to accomplish independently. They need other.net and example.org to share some common information (like an email address) to make the link. For logged out users, it should be impossible without resorting to fingerprinting. This was Firefox and Safari's entire reason d'etre for launching Total Cookie Protection and Intelligent Tracking Protection. I don't believe CNAME cloaking overcomes their protections, or at the very least, I don't see where this paper explains an attack vector.
- tatersolid 6y ago
  Except your auth tokens on the each site should be opaque identifiers and can’t be linked. Unless both sites are using the disaster that is JWT/JOSE as their token format with signing only and not encryption.
  - fluidcruft 6y ago
    The reason sites are adding these CNAME tricks is specifically to enable evil.com to track you across sites to sell ads. So it's not just the CNAME trick, it's specifically what evil.com is doing that links accounts across sites. The bottom line is that evil.com would not be asking sites to install CNAME tricks in their domains if evil.com cannot leverage those tricks to track users across sites. That should be obvious.
- thrwwy0304 6y ago
  > The bottom line is that evil.com would not be asking sites to install CNAME tricks in their domains if evil.com cannot leverage those tricks to track users across sites. That should be obvious. This is the leap I believe is incorrect. The paper doesn't explain how CNAME cloaking helps evil.com track users across sites. It says that it does, but it doesn't actually explain the attack vector. It is far more plausible to me that CNAME tricks are being added so that evil.com can track a user on an individual site. When uBlock Origin is putting a hard block on all traffic to evil.com, there's still quite a bit to be gained by shifting evil.com to evil.foo.com if that means requests start succeeding again. Another poster said something similar here: https://news.ycombinator.com/item?id=26349987 https://news.ycombinator.com/item?id=26349987

tinus_hn 6y ago

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.

fluidcruft 6y ago
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.
- tinus_hn 6y ago
  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 .
  - fluidcruft 6y ago
    Yeah, exactly. awesome.example.org is the example.org site's code and tracking-you.example.org is evil.com's code.