Hi all, Having somewhat of a web security and having done some DNS work ( https://henrybirgelee.com/ ) I did want to weigh in a bit on this conversation. I do find the vulnerabilities discussed here quite significant in both the Direct XSS over DoH form (when there is a web app running on the same domain as a DoH endpoint) and the CSP-Bypass over DoH.
Beyond just these attacks, being able to upload arbitrary (potentially malicious) content onto the trusted domain of a reputable vendor (like Cloudflare or Google) bypasses many security controls put in place at various layers of the network stack. Imagine an email phishing scanner looking for suspicious links in emails. A Cloudflare or Google domain will likely not get filtered but could contain malicious phishing content. Similarly a user's own anti phishing training may even instruct users to focus on domain names and clicking a link that ends in .google like dns.google (which is well understood to be Google controlled) may cause a user to let their guard down. I suspect only a power user would realize that the link was not actually google controlled and was in fact a DNS query to arbitrary 3rd party content. Similarly imagine a filtering firewall or a network packet capture analyzer trying to understand malicious traffic based on destination domain (from SNI or DNS queries) being completely blindsided by malicious web content injected into a trusted domain. In general domains and subdomains represent trust boundaries. Many different security technologies pick up on these trust boundaries. XSS and Content Security Policy are just two of such technologies but there are a lot. Being able to put malicious content onto the domains of some of the largest and most trusted vendors on the Internet enables many different attacks. I would urge the working group to consider practical mitigations to ensure DoH responses are never interpreted as web content by browsers and avoid a hope and prey approach (i.e., that people will never run DoH on a domain that actually matters or that the implications of the attack will somehow be fully understood by the plethora of security software out there that assumes domain names are administrative boundaries). Best, Henry P.S. Also fun fact, before .well-known became a thing CAs could use various pieces of content placed in a web root to perform domain control validation. Being able to put arbitrary content on a 3rd party's domain can be very problematic. On Wed, Apr 1, 2026 at 11:12 AM Matthias Gierlings <matthias.gierlings= [email protected]> wrote: > Kevin P. Fleming wrote: > > On Tue, Mar 31, 2026, at 18:45, Matthias Gierlings wrote: > >> Assume you operate some website under the domain "benign.example". > >> You also operate a DoH endpoint under "https://benign.example/dns-query > ". > > It sounds like the initial recommendation then would be to never operate > a DoH endpoint on the same domain as any websites - use a distinct domain > for that purpose. > > That would be one way to deal with the impact of the Direct-XSS-Attack > on co-located websites at least. Unfortunately the RFC does neither > explain the implications of co-locating DoH endpoints with websites > nor does it forbid such co-located deployments, which do already exist > today. > > Even if there is no co-located website present, it is problematic when > attackers can deliver content of their choice within a web-origin > that is not their own. > > Simply avoiding co-location of websites with DoH service endpoints > does not prevent the CSP-Bypass-over-DoH which also exploits > situations where websites white-list trusted third parties, > e.g. cloud providers or CDNs, as content sources. What makes things > worse in this situation is that the website operator of a site > "https://benign.example";, who depends on the trusted third party "CDN" > (https://cdn.example), has no control over whether https://cdn.example > operates a DoH endpoint in their origin or not. It might be that > cdn.example load-balances their services among different nodes, e.g. > node1.cdn.example, node2.cdn.example, ..., nodeN.cdn.example. So > the dependent website operator of benign.example adds "script-src: > https://*.cdn.example"; to their CSP. Now assume CDN decides to set up > a DoH endpoint https://doh.cdn.example/dns-query. This endpoint is > also white-listed in the CSP and now has become an injection point > not only for benign.example but for all other websites depending on > CDN as a trusted third party in the same way benign.example does. > Meanwhile the operators of those dependent sites might not even be > aware that this DoH service has been deployed by CDN. > > We cannot stress enough that the underlying problem which enables > XSS-over-DoH is the choice to rely on the protocol message format > (HTTP) and the well known service part of a different protocol, i.e. > HTTPS, for DoH. This means that DoH servers can be easily mistaken > for web servers, especially by clients that don't support DoH at all. > Of course at the current stage of deployment it is not possible to > revise this design decision of the DoH protocol. > > Yet both attacks Direct-XSS and the CSP-Bypass can be mitigated by > introducing Explicit Content Type Negotiation (ECTN)[1]. Deploying > ECTN would even allow for co-location of DoH endpoints with websites > because it eliminates the protocol confusion and enables DoH servers > to clearly distinguish between misguided web-request and intentional > DoH-requests. DoH servers implementing ECTN no longer deliver > responses to web-requests accidentally directed at them but only to > intentional DoH requests. This deprives the attacker of the ability > to deliver content in a non-DoH-context, and even works for non-DoH > aware clients. > > -- > Kind regards > > Matthias Gierlings > > [1] XSS-over-DoH: On the Adverse Side Effects of DoH on Web > Security (IETF Preprint Version, p. 10f, §5.1 "Explicit > Content-Type-Negotiation Protects both Non-DoH-Aware and DoH-Aware > Implementations." > ( > https://mailarchive.ietf.org/arch/msg/dnsop/cQ_mFaRYeOvpr4gWfIAoL1e5hDg/2/) > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
