Sec21 Squarcina
Sec21 Squarcina
Sec21 Squarcina
Marco Squarcina1 Mauro Tempesta1 Lorenzo Veronese1 Stefano Calzavara2 Matteo Maffei1
1 TU Wien 2 Università Ca’ Foscari Venezia & OWASP
May be required
js
Capability Description
CORS
Expired Domains headers access and modify HTTP headers
html js arbitrary JavaScript code execution
Discontinued Services postMessage
html alter the markup of the website with the exclusion of JavaScript
content alter the textual content of the website with the exclusion of embed tags,
content
frames and JavaScript code
Deprovisioned Cloud Inst.
domain relaxation file host arbitrary files
file https operate a website under HTTPS with a valid certificate
https CSP Note: js subsumes both html and content, since it is possible to
edit the DOM by using JavaScript. Similarly, html subsumes content.
3.3 Web Threats Cookies can be issued with the Domain attribute set to an
ancestor of the domain setting them, so as to share them with
We identify for the first time a comprehensive list of web all its subdomains. For example, good.foo.com can issue a
security threats posed by related-domain attackers, discussing cookie with the Domain attribute set to foo.com, which is sent
in particular the scenarios where a related-domain attacker to both good.foo.com and evil.foo.com. Hence, related-
might have an advantage over traditional web attackers. While domain attackers can trivially break cookie confidentiality and
there exists ample literature on threats to cookies confidential- abuse of stolen cookies [62], e.g., to perform session hijack-
ity and integrity posed by related-domain attackers [15, 62], ing. The Domain attribute poses risks to cookie integrity too:
in this work we focus on a complete account of how related- evil.foo.com can set cookies for good.foo.com, which can
domain attackers affect web application security by exploring be abused to mount attacks like session fixation. Note that
less-studied mechanisms. the integrity of host-only cookies is at harm too, because a
related-domain attacker can mount cookie shadowing, i.e., set
3.3.1 Inherent Threats a domain cookie with the same name of a host-only cookie to
confuse the web server [62].
Related-domain attackers sit on the same site of their target Site operators can defend against such threats by careful
web application. This is weaker than sharing the same origin cookie management. For example, they can implement (part
of the target, which is the traditional web security boundary, of) the session management logic on top of host-only cookies,
yet it suffices to abuse the trust put by browser vendors and which are not disclosed to related-domain attackers. More-
end users on same-site content. We discuss examples below. over, they can use the __Host- prefix to ensure that security-
Trust of End Users. End users might trust subdomains of sensitive cookies are set as host-only, thus ensuring their in-
sites they are familiar with more than arbitrary external sites. tegrity against related-domain attackers.
For instance, attackers could exploit the residual trust asso- Capabilities. The capabilities required by a related-domain
ciated with the subdomain’s prior use [30] or deceive users attacker to break the confidentiality of a domain cookie de-
into inserting their passwords provided by a password man- pend on the flags enabled for it: if the cookie is HttpOnly,
ager [56]. This is particularly dangerous on some mobile it cannot be exfiltrated via JavaScript and the headers ca-
browsers, which display only the rightmost part of the domain pability is needed to sniff it; otherwise, just one between
due to the smaller display size, hence a long subdomain might headers and js suffices. If the Secure flag is enabled, the
erroneously look like the main site. Attackers could similarly cookie is sent only over HTTPS, hence the https capabil-
abuse the trust inherited from the apex domain to use com- ity is also required. As to integrity, all cookies lacking the
promised subdomains for the distribution of malware or other __Host- prefix have low integrity against a related-domain
types of dangerous content [34]. attacker with the headers or js capabilities, since they are af-
Site Isolation. Site Isolation is a browser architecture first fected by cookie shadowing. There is one exception: cookies
proposed and implemented by the Google Chrome browser, using the __Secure- prefix have low integrity only against
which treats different sites as separate security principals related-domain attackers which additionally have the https
requiring dedicate rendering processes [44]. These processes capability, since these cookies can only be set over HTTPS.
Note: Deployment of CSP only considers policies that are not trivially exploitable by a web attacker (§4.3.2) and whitelist one or more related domains. CORS policies
are only exposed to requests coming from whitelisted origins [18]: for the deployment we report the count of domains/sites vulnerable either to web attackers or related-domain
attackers that were discovered during dynamic testing. postMessage is omitted since related-domain attackers have no gain compared to web attackers.
40
16 8
60 5 35
14 50 7
50 30
12 4 6
40
% Potentially Vulnerable
% Potentially Vulnerable
% Potentially Vulnerable
25
10 40 5
% Vulnerable
% Vulnerable
% Vulnerable
3
30 20
8 4
30
15
6 2 3
20
20
4 2 10
10 1 10
2 1 5
0 0 0 0 0 0
1
8
16
64
24
48
16 2
65 8
32
96
32 4
13 36
72
Tr t (2 4)
W har (6 )
(3 )
4 )
H g ( 7)
)
u 80 )
8)
si t (3 5)
Fi nol d ( )
Ad g ( )
5)
4)
op n ( 9)
G inm s (6 8)
(9 )
O t (1 )
M er 32
5
9
er en 896
4
7
6
ss 58
12
38
76
60 0
80 0
10 00
14 0
16 00
20 00
24 00
26 00
30 00
36 00
40 00
46 00
50 00
25
51
40 0
12 00
18 00
22 00
28 00
32 00
34 00
38 00
42 00
44 00
48 00
4
ng 3
Bu en 04
og 93
ci (85
34
(4
21
ch Fo 37
eb in 35
ti n 0
0
ul 44
10
20
10
00
00
40
81
0
0
0
pi 43
ea 2
6
ic (13
os 16
ew 14
8
0
0
0
0
20
0
0
0
0
(1
S
nm t (
(
So s
uc DN
al
el
l
io
Number of Subdomains Tranco Rank
Sh tio
av
ne
th
Ed ic
H
a
N
am
al
S
a
yn
rt
le
ov
Te
D
te
En
(a) # Subdomains (b) Tranco Rank (c) Categories
subdomains of an already mapped domain. Moreover, 8 ser- of them in the list, leaving their massive user base at risk.
vice providers perform an automatic redirection from the www We reported this major flaw to the FreeDNS maintainer, who
subdomain to the parent domain. Therefore, users of these acknowledged it but took no action, as it would be impossible
services might erroneously assume that the www subdomain is to maintain an updated list of thousands of domains in the
implicitly bound to their account and cannot be claimed by PSL, given the lack of an API to manage PSL entries.
others. Only Shopify and Launchrock do not prevent this sub-
domain from being mapped to different accounts. We reported
to GitHub and Shopify, two of the major service providers, 5.2 Web Threats
the vulnerabilities discovered on the domain ownership verifi-
We now turn the attention to the web application security
cation process. GitHub acknowledged the problem and told
implications of our analysis, as summarized in Tables 3 and
us that they “[...] are exploring various changes to the cus-
further detailed in Table 6.
tom domain flow that will improve this situation by requiring
formal domain ownership verification”. Shopify awarded us We start by discussing confidentiality and integrity of ses-
$1,000 for the report and shipped a fix on April 12, 2021. sion cookies. Overall, our crawler collected 85,169 cookies,
out of which 24,924 have been labeled as session cookies by
Dynamic DNS Services. The adoption of the PSL across our heuristic. Among these, we identify 3,390 (14%) cookies
different dynamic DNS providers is shown in Table 5, together from 5,051 (33%) domains on 687 sites (81%) whose confi-
with the number of domains that a user can choose from. We dentiality can be violated by a related-domain attacker. This
observed that only 2 providers listed all their domains in shows that related-domain attackers can often get access to
the PSL. Noip and DynDNS left out a small number of the session cookies, which may enable attacks like session hijack-
domains they offer, but it is not clear to us whether this is ing. Our analysis also shows that the state of cookie integrity
due to negligence or if this is a deliberate choice. Instead, is even worse: in particular, we identify 24,689 (99%) ses-
FreeDNS, with more than 50k domains, did not include any sion cookies from 14,964 (99%) domains on 834 (99%) sites
Cookies
all 23,400 857
campaignmonitor V − V content I 23,178 845
cargo V Ë V js C 5,051 687
feedpress V − − html session 15,179 846
I 14,964 834
gemfury V − − file https
github V − Ë js file https script inclusion 1,144 260 901 (0) 212 (0)
helpscout V − V js file https style inclusion 961 232 930 (0) 225 (0)
CSP
jetbrains Ë − V content object inclusion 1,027 250 598 (+12) 123 (+5)
launchrock V V V js https frame inclusion 967 229 664 (+45) 152 (+12)
ngrok ? ? Ë js file headers https framing control 1,676 360 344 (+97) 59 (+21)
persona V Ë V js https
CORS
pingdom V − − js all - - 2,254 (+224) 488 (+51)
readme.io V − V js https with credentials - - 179 (+63) 71 (+27)
shopify V V V js https
smartjobboard V Ë V js https postMessage 14,045 823 14 (0) 11 (0)
statuspage Ë − V js https
Domain Relaxation 97 61 57 29
strikingly ? ? V js https
surgesh Ë Ë V js https Note: C and I denote cookie confidentiality and integrity. Numbers within
tumblr V − V js file https parenthesis represent the improvement compared to a web attacker; when missing, the
uberflip ? ? − js https web attacker cannot perform the attack.
uptimerobot V − − content
uservoice ? ? V js https
webflow ? ? V js https
wordpress Ë Ë V js https increase in the attack surface for frame injection: 45 (+7%)
worksites V Ë V js https
domains are exploitable exclusively by controlling one of the
Note: We use the following notation: service not affected (Ë); service is vul-
nerable (V); the conditions of redirect and PSL do not apply (−); could not evaluate, vulnerable subdomains identified in our dataset.
e.g., due to payment required, no public registration form, etc. (?). Helpscout allows As to the other mechanisms, CORS deployments are sig-
to host only arbitrary active content files (js, css); Gemfury allows to host only
arbitrary passive content files (images, media, ...); Launchrock implicitly associates nificantly more at risk against related-domain attackers rather
every subdomain to the mapped domain, not only the www subdomain. than against traditional web attackers. In particular, we iden-
tify 224 (+11%) new exploitable cases, including 63 (+54%)
Table 5: PSL on dynamic DNS services.
cases with credentials. Note that the use of CORS with cre-
Service # Domains PSL dentials is particularly delicate from a security perspective,
afraid (FreeDNS) 52,443 V 0/52,443 hence the strong percentage increase in the number of vulner-
duckdns 1 Ë 1/1 able cases is concerning. Domain relaxation, instead, can be
dyndns 293 V 287/293
noip 91 V 85/91 abused by related-domain attackers in 57 out of 97 domains
securepoint 10 Ë 10/10 (59%) making use of this mechanism. Exploiting domain re-
laxation puts a related-domain attacker in the same origin of
the target web application, hence bypassing all web security
which do not have integrity against a related-domain attacker, boundaries: this is a critical vulnerability, which deserves at-
hence may enable attacks like session fixation and cookie forc- tention. Domain relaxation is a bad security practice, which
ing. This increase comes from the fact that related-domain should better be avoided in the modern Web. Finally, our anal-
attackers can compromise the confidentiality of domain cook- ysis of postMessage shows that all sites suffering from unsafe
ies alone, while they can break the integrity of any cookie by programming practices are already vulnerable against web
exploiting cookie shadowing [62]. The fraction of domains attackers, i.e., for this specific attack vector related-domain
not affected by integrity issues is only due to the lack of ca- attackers are no more powerful than traditional web attackers,
pabilities available for the subdomain we could possibly take at least based on the collected data. In other words, sites either
over. The only robust way to improve cookie integrity in this do not enforce any security check or restrict communication
setting is the adoption of the __Host- prefix, which is unfor- to selected individual origins: this might be a consequence of
tunately negligible in the wild: we only identified one cookie the postMessage API granting access to origin information,
using it in our dataset. rather than site information directly.
Concerning CSP, the first observation we make is that, as
reported by previous studies [15,46,57], the majority of CSPs
in the wild suffer from incorrect configurations, voiding their 6 Related Work
security guarantees even against web attackers. Remarkably,
however, related-domain attackers are more powerful than Related-Domain Attackers. The notion of related-domain
traditional web attackers for real-world CSPs, being able to attacker was first introduced by Bortz, Barth, and Czeskis [9].
bypass the protection mechanism on 139 additional domains. Their work identified the security risks posed by related do-
This is apparent for object injection, frame injection, and mains against (session) cookies and proposed a possible solu-
framing control. For example, we quantified the following tion called origin cookies. A similar defense mechanism, i.e.,
[8] K. Borgolte, T. Fiebig, S. Hao, C. Kruegel, and G. Vigna. [23] E. Foudil and Y. Shafranovich. A File Format to Aid in
Cloud Strife: Mitigating the Security Risks of Domain- Security Vulnerability Disclosure, 2020.
Validated Certificates. In NDSS, 2018.
[24] FreeDNS. Free DNS Hosting, Dynamic DNS Hosting,
[9] A. Bortz, A. Barth, and A. Czeskis. Origin Cookies: Static DNS Hosting, subdomain and domain hosting.
Session Integrity for Web Applications. In W2SP, 2011. https://freedns.afraid.org/, 2020.
[36] P. Mockapetris. RFC1035: Domain Names - Implemen- [51] M. Steffens and B. Stock. PMForce: Systematically
tation and Specification, 1987. Analyzing postMessage Handlers at Scale. In CCS,
2020.
[37] Mozilla. Mixed content. https://developer.
mozilla.org/en-US/docs/Web/Security/Mixed_ [52] B. Stock, G. Pellegrino, F. Li, M. Backes, and C. Rossow.
content. Didn’t You Hear Me? - Towards More Successful Web
Vulnerability Notifications. In NDSS, 2018.
[38] Mozilla. Public Suffix List. https://publicsuffix.
org/. [53] B. Stock, G. Pellegrino, C. Rossow, M. Johns, and
M. Backes. Hey, You Have a Problem: On the Fea-
[39] M. Nottingham. RFC8615: Well-Known Uniform Re- sibility of Large-Scale Web Vulnerability Notification.
source Identifiers (URIs), 2019. In USENIX Security, 2016.