With the rise of ad and content blockers<\/strong> (think Ghostery<\/a> and uBlock Origin<\/a>), as well as browser tracking protections<\/strong> (see www.cookiestatus.com<\/a>), marketing technology vendors have their work cut out for them. And when I refer to \u201ctheir work\u201d<\/strong>, I mean they have to proactively identify and exploit any loopholes they can find to keep on collecting their precious data.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n In this article, I\u2019ll take a look at one such exploit vector, the Canonical Name ( The phenomenon of mapping subdomains to third-party services isn\u2019t confined to just advertising and marketing technology industries, though. In this article, I\u2019ll also introduce you to the extensive body of research collected by Zach Edwards<\/a>.<\/p>\n This research shows how countless subdomains of high value and importance (think government, education) have been compromised and primed for stealing credentials written in first-party cookies.<\/p>\n It\u2019s important to raise awareness of the risks involved with mapping subdomains to third party servers. Even though much of Zach\u2019s research concerns scenarios where subdomains have been taken over by attackers, the end result is the same: the third party has access to data beyond what the site owner or business might have considered.<\/p>\n But before we dig into the risks themselves, it\u2019s important to understand how we got to the point of surrendering our own domain namespace to third-party vendors and services.<\/p>\n \n \n Subscribe to the Simmer newsletter<\/a> to get the latest news and content from Simo Ahava into your email inbox!\n <\/p>\n <\/span><\/p>\n The fact is that storage access in third-party context<\/a>, colloquially referred to as \u201cthird-party cookies\u201d, has become unstable and unreliable as the foundation for any data collection scheme, regardless of browser vendor:<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n What\u2019s the solution for vendors that want to continue with their cross-site tracking<\/a> shenanigans? Well, if third-party context<\/strong> is too unreliable to build any business logic for, it\u2019s time to take a look at first-party context<\/strong>.<\/p>\n When a vendor decides to move from third-party to first-party context, it typically means one or more of the following.<\/p>\n They start decorating incoming links<\/a><\/strong> to the site from the vendor\u2019s platform where the user has been identified e.g. via a login.<\/p>\n This is how Facebook<\/strong> works, for example, as every single link you click in Facebook will be appended with the <\/p>\n <\/a><\/p>\n<\/div>\n They start utilizing browser fingerprints<\/a><\/strong> to identify the user from one HTTP request to the next. Fingerprinting is dangerous because it is completely stateless – there\u2019s no need to persist any information in the browser.<\/p>\n The user is disarmed of options to actively prevent this. This has led fingerprinting to become one of the rare areas where there is practically universal consensus among browser vendors that it is a Bad Thing and must be prevented.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n They request the site owner to run their scripts locally or to use local routers<\/strong>. This way they can circumvent ad blockers targeting the vendor domains.<\/p>\n <\/p>\n <\/a><\/p>\n<\/div>\n They request the site owners to reserve a subdomain<\/em> in their domain namespace<\/strong>, which is configured to point to the vendor\u2019s servers.<\/p>\n All of these approaches have been designed to avoid the heuristics in browsers and browser extensions that target third-party trackers. The reliability of these workarounds depends on how easy the site owner is to hoodwink into actively participating in setting them up.<\/p>\n Link decoration, for example, doesn\u2019t require the site owner to do anything but add the vendor JavaScript to the site. However, it\u2019s not the most reliable exploit since blockers are most likely already preventing access to the most popular CDNs owned by the tracking vendors.<\/p>\n The last option in the list ends up being the most robust one because it requires the site owner to actively and knowingly collude with the third party to improve the quality of the data collection. This is the exploit we\u2019ll be discussing in the rest of the article, as it has the biggest ramifications for end-user privacy and data security.<\/p>\n This article<\/a> shows you how some vendors in the advertising and marketing technology space are approaching the restrictions to third-party context. They are directly contacting their customers and asking for their help in keeping the service alive.<\/p>\n The gist is typically that the site needs to reserve a subdomain (e.g. Alternatively, the site can set up Once the DNS record resolves, all requests to So, why go through all this trouble? Well, there are a couple of reasons:<\/p>\n The site doesn\u2019t have to relax its Content Security Policies<\/a> to allow third-party domains to load and run their scripts on the site. This reduces the friction in deploying the third-party service on the site.<\/p>\n<\/li>\n It\u2019s so easy<\/em> to setup a While Since the service is now running in first-party context with the rest of the site, the service can leverage first-party cookies<\/strong>, even those set with the When the browser sends an HTTP request to a target address, that request will include all the cookies<\/strong> written on the target domain and any domains \u201chigher\u201d in the hierarchy, all the way to the top-most privately controlled domain name.<\/p>\n For example, when If the source and target of the request are same-site<\/strong> (i.e. they share the top-most privately controlled domain name), the request happens in first-party context<\/strong>, which is largely unrestricted<\/strong> by browsers and plugins today.<\/p>\n When you surrender, either willingly by mapping the domain yourself or inadvertently via a takeover, a subdomain to a third party, you open your business for potentially horrendous data and credential leaks.<\/p>\n <\/p>\n <\/a><\/p>\n Authentication cookie with which the browser is logged in with my Google ID<\/span><\/p>\n<\/div>\n Since the web server at the end of an HTTP request is privy to a large subset of first-party cookies set on any given site, things like state<\/strong> and authentication tokens<\/strong> are automatically logged by the web server owned by the vendor. This is because many sites still set them on Gaining control of a subdomain also opens up possibilities for a number of different, very dangerous exploits<\/a>, ranging from cross-site scripting attacks to intentional brand defamation.<\/p>\n Sometimes these cookies contain personally identifiable information such as email addresses<\/strong> and user names<\/strong>, allowing vendors to enhance the user\u2019s cross-site tracking profile without them being able to do anything about it.<\/p>\n <\/p>\n <\/a><\/p>\n PII and authentication information in first-party cookies<\/span><\/p>\n<\/div>\n Typically, there are privacy policies and lots of red tape in place, where the vendors offer complicated promises that they will not misuse the information logged by their web servers. But these practices vary wildly.<\/p>\n Furthermore, because everything happens behind the curtains of server-to-server communications, it\u2019s practically impossible for independent auditors to know what\u2019s going on.<\/p>\n And this is the main warning of this article:<\/p>\n When you map your subdomain to a third-party service, you are sending much more data to the third party than you might have bargained for.<\/strong><\/p>\n Compare this with sending the request directly to the vendor-specific domain. By default, these requests would only include (third-party) cookies written on the vendor domain. Any other information would need to be encoded with JavaScript, which can be parsed and audited by anyone visiting the site.<\/p>\n But with a subdomain mapping, all first-party cookies available on that domain will be sent, including those flagged as Zach Edwards<\/a> is one of those people on Twitter you simply must<\/strong> follow. He\u2019s been conducting exhaustive<\/strong> research into many areas intersecting internet security and digital marketing and analytics. One of his pet peeves at the moment is something he\u2019s dubbed the PickaFlick.com<\/strong> attacks.<\/p>\n In these scenarios, an attacker takes control of subdomains (usually DNS records left dangling<\/a>), and then starts stuffing search engine results<\/strong> with bogus links, hoping the visitor will click one of them.<\/p>\n <\/p>\n <\/a><\/p>\n From https:\/\/bit.ly\/epic-games-hack<\/span><\/p>\n<\/div>\n If the visitor does click such a link, that HTTP request will include all the first-party cookies available on that particular subdomain. See the previous chapter for examples of what type of information can be encoded in these cookies.<\/p>\n The screenshot above is from I recommend you read Zach\u2019s article, as it shows how widespread and long-standing the PickaFlick.com attacks (and similar) are. It\u2019s also shocking how oblivious so many site and service owners are to trouble brewing in their own backyards.<\/p>\n Go through your site\u2019s search results with a search query like <\/p>\n <\/a><\/p>\n<\/div>\n This diversion to Zach\u2019s research isn\u2019t necessarily an indictment of To avoid subdomain mappings from harming your business, there are some mitigations you can act upon.<\/p>\n Follow the instructions in the previous chapter to see if you have compromised subdomains<\/strong>. If so, make sure you remove these subdomains from your DNS registry. It would be a good idea to report this to the service you use for your DNS, so that they can take appropriate action with their other customers as well.<\/p>\n<\/li>\n Make sure all state and authentication tokens, and really anything that can be used to impersonate a user<\/strong>, are written on a subdomain that you have control over<\/strong>. Make sure they are not<\/strong> written directly on the top-most privately controlled domain name. Make sure they are Make sure your Content Security Policy doesn\u2019t just wildcard<\/strong> all your subdomains ( Periodically audit<\/strong><\/a> cookies accessed in both first- and third-party contexts across your sites.<\/p>\n<\/li>\n<\/ol>\n It really boils down to the trust<\/strong> you place in the vendors to whom you are mapping subdomains, the governance<\/strong> you have over the data flows, assets, and storage access across your sites, and processes<\/strong> you have in place for periodically auditing these perilous gateways to potentially brand-decimating leaks.<\/p>\n Why go through the trouble of ranting about Well, this is an insidious attack vector because it can be orchestrated with the best of intentions. It needs more exposure. More and more vendors are requesting subdomain mappings, and it\u2019s important that site owners know what they\u2019re subscribing to.<\/p>\n Moving vendor services to first-party context isn\u2019t necessarily a universally bad thing<\/em>. As a site owner, you are actively participating in vetting the services integrated on your site, and by mapping DNS records to third parties, you are proactively taking responsibility for the data streams and flows to and from your site. At least, in theory.<\/p>\n The problem isn\u2019t necessarily related to the contracts and terms of services you sign with the vendors, which promise to restrict the types of data accessed in these requests. No, the problem is with this aspect of the HTTP protocol in general.<\/p>\n Allowing cookies to pass unchecked through In the European Union, the ePrivacy Directive<\/strong> guides businesses to be aware and audit all<\/em> keys and values stored in all<\/em> browser storage at all<\/em> times. Having an up-to-date audit of first-party cookies, for example, reduces the risk of leaking this information to third parties.<\/p>\n If you need to manage state, authentication, and\/or personally identifiable information in cookies, make sure they\u2019re not set in the root of the domain namespace you control. That way you mitigate the risk of this information leaking to server endpoints you have no control over.<\/p>\n Just be vigilant<\/strong> and map those data flows<\/strong>. That\u2019s a good way to reduce a huge<\/em> amount of risk embedded in how your site, app, or service persists and processes user data.<\/p>\n<\/p><\/div>\n![\"What's](\"https:\/\/www.simoahava.com\/images\/2020\/06\/whats-in-a-cname.jpg#ZgotmplZ\")
<\/p>\nCNAME<\/code>) DNS record, in particular.<\/p>\n
\n X<\/span><\/p>\n
\n The Simmer Newsletter<\/strong>\n <\/p>\nThe perils of the third-party<\/h2>\n
\n
SameSite=Lax<\/code><\/a> unless the cookie is manually updated with the appropriate flag when set.<\/li>\n<\/ul>\n\n
SameSite=Lax<\/code> is an attribute that specifies the cookie can only be accessed in first-party context. While not a tracking protection per se, it\u2019s still a fairly significant move in helping auditors identify which cookies have been flagged for potential cross-site access.<\/p>\n<\/blockquote>\n![\"Firefox](\"https:\/\/www.simoahava.com\/images\/2020\/06\/firefox-report.jpg#ZgotmplZ\")
<\/p>\nThe bliss of the first-party<\/h2>\n
fbclid<\/code> parameter. After that, any Facebook (or partner) script running on the site can take that parameter from the URL and send it back to the vendor. Thus Facebook will know that the person for whom the hash was created visited your site.<\/p>\n![\"Facebook](\"https:\/\/www.simoahava.com\/images\/2020\/06\/facebook-link.jpg#ZgotmplZ\")
<\/p>\n![\"Browser](\"https:\/\/www.simoahava.com\/images\/2020\/06\/browser-fingerprint.jpg#ZgotmplZ\")
<\/p>\n![\"Router](\"https:\/\/www.simoahava.com\/images\/2020\/06\/router-script.jpg#ZgotmplZ\")
<\/p>\nSubdomain mappings<\/h2>\n
tracking.domain.com<\/code>), which is then set to point to a vendor domain name (e.g. identity.vendor.com<\/code>) using a Canonical Name (CNAME<\/code>) DNS record.<\/p>\n\n
A\/AAAA<\/code> records that point directly to the vendor server IP address, but this is rare. With a CNAME<\/code>, the vendor has the liberty of shuffling around the IP ranges of their servers without breaking the link to the mapped domain names.<\/p>\n<\/blockquote>\ntracking.domain.com<\/code> are received by the vendor server behind identity.vendor.com<\/code>.<\/p>\n\n
CNAME<\/code> record. There\u2019s no need to configure complicated reverse proxies or to create multiple A\/AAAA records. It\u2019s (typically) just a single DNS change that anyone with adequate access can do.<\/p>\n<\/li>\nidentity.vendor.com<\/code> is most likely in most of the blocklists for browsers and browser extensions, tracking.domain.com<\/code> most likely isn\u2019t. This is a pretty solid way to circumvent ad blockers.<\/p>\n<\/li>\nHttpOnly<\/code> flag<\/a>.<\/p>\n<\/li>\n<\/ol>\nFirst-party cookies and data leaks<\/h2>\n
owned.domain<\/code> sends an HTTP request to sub.sub.owned.domain<\/code>, that request will include all the cookies written on sub.sub.owned.domain<\/code>, sub.owned.domain<\/code>, and owned.domain<\/code>.<\/p>\n![\"Authentication](\"https:\/\/www.simoahava.com\/images\/2020\/06\/sacsid.jpg#ZgotmplZ\")
<\/p>\nowned.domain<\/code>, making them available to all<\/em> subdomains of the domain name.<\/p>\n![\"PII](\"https:\/\/www.simoahava.com\/images\/2020\/06\/cookies.jpg#ZgotmplZ\")
<\/p>\nHttpOnly<\/code>. These HttpOnly<\/code> cookies can\u2019t be accessed with client-side script at all, which might lull site owners to a false sense of security.<\/p>\n![\"From](\"https:\/\/www.simoahava.com\/images\/2020\/06\/epic-games-hack.jpg#ZgotmplZ\")
<\/p>\nthehousepartyapp.com<\/code>, which Zach quite elaborately<\/a> reported to Epic Games as having been compromised by subdomain takeovers. This was initially in response to Epic Games\u2019 ludicrous $1,000,000<\/strong> bounty for proof of a smear campaign related to a possible hacking incident.<\/p>\nsite:mydomain.com \"free ebook\"<\/code> and see if bogus results turn up. If they do, it\u2019s time for a DNS record audit. Make sure to eliminate any that you don\u2019t recognize or control the endpoint for anymore.<\/p>\n![\"Wichita.gov](\"https:\/\/www.simoahava.com\/images\/2020\/06\/wichita-gov-attack.jpg#ZgotmplZ\")
<\/p>\nCNAME<\/code> exploits themselves, but they do exemplify how perilous and fragile this aspect of the HTTP protocol is.<\/p>\nPrevention measures<\/h2>\n
\n
httpOnly<\/code> and secure<\/code>. Make sure they are SameSite=Strict<\/code>, unless you need them in a third-party context.<\/p>\n<\/li>\n*.owned.domain<\/code>). Allow only those domains that you have vetted and have governance over<\/strong>.<\/p>\n<\/li>\nClosing thoughts<\/h2>\n
CNAME<\/code> redirects, when they\u2019ve been so eloquently covered by this incredible article by Romain Cointepas<\/a>? Why discuss subdomain takeover attacks when Zach Edwards has already done all the legwork<\/a>?<\/p>\nCNAME<\/code> redirects to possible tracking domains is where the problem lies. Browsers don\u2019t (yet) have the capability to detect hazardous CNAME<\/code> chains, but it is a feature set I wouldn\u2019t be surprised to see in their roadmaps.<\/p>\n