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]
