Could an angry developer upload a file with an image extension, actually containing some Javascript magic, and send the link to an admin and get admin access?

Yes. The actual attacks are generally more obscure, like "upload a .html document, then trick an administrator into viewing it on an iPad, where Content-Disposition is ignored, so the scripts in the file run with domain permissions", but basically the class of attacks this protects against allows registered users to escalate by XSS-ing administrators. There are some similar flavors of this with Java applets and Flash.

Few installs are concerned about this, and compromising administrator accounts is often not much of an escalation anyway (see https://secure.phabricator.com/book/phabricator/article/users/#administrators), and installs often found this confusing/burdensome, and we didn't have an "ignore" option at the time, so that's what shaped T2380 and why it hasn't been a priority to fix.

Is this Phabricator specific?

None of the attacks are Phabricator specific. This class of attack is (one of the reasons) why sites like Facebook and Google serve user content from alternate domains.

Does this mean that a different subdomain is better than nothing?

Slightly, but not by much. I think it defuses some of the applet stuff a bit, and makes some other attacks slightly more challenging, but doesn't fundamentally provide protection from this class of attack.

See also T6994.

how come you don't have a separate files domain for secure.phabricator.com

Compromising an administrator account on this install doesn't really let you do anything interesting that you can't do with a general user account. Until recently, we didn't even have any private information on this install.

Thank you very much for the detailed response. I hope a variant of your explanation will end up in the description for security.alternate-file-domain.

I wonder whether a different subdomain is really not enough to thwart a Javascript attack (https://en.wikipedia.org/wiki/Same-origin_policy), but if you are sure it isn't, it would make sense to emphasize this in the description. Currently, the description reads as if a different subdomain is ok, but a different domain would be better.

Can someone please elaborate *why* an entirely different domain should be used? From reading the Cross-Site Scripting, Cross-Site Request Forgery, Same-Origin Policy, Cross-Origin Resource Sharing and Content Security Policy articles on Wikipedia, I understand that any different scheme://hostname:port/ combination will already be sufficient to invoke the Same-Origin policy and block requests.

Further, I would like to know whether I need to manually configure a Content Security Policy header and with which values. My understanding of the abovementioned articles is that the user-content-domain technique is only effective if I serve all intentionally active content from one host (which I allow via CSP) and all user content from another (which I do not allow in the CSP).

x.y.com can use document.domain to gain access y.com, so that's one example of two different host names being able to access the same data.

x.y.com can also read and set cookies on y.com.

By coordinating through an iframe, x.y.com can access z.y.com: documents on both subdomains domain lower, then one iframes the other one and can reach inside it (or could a few years ago, at least). The z.y.com page has to be an accomplice here, but the amount of work it needs to do is very small (run one JS assignment statement).

In practice, it is unlikely that any of these attacks would allow an attacker to meaningfully escalate their access, but using an entirely separate domain defuses these vectors completely. Using a subdomain does not. Using a subdomain of the Phabricator domain (cdn.secure.phabricator.com) is even more likely to be dangerous because of cookie rules.

unlikely that any of these attacks

Actually, there is a somewhat-practical attack on cookies which allows session fixation (which motivated GitHub to move all user content to github.io):

https://github.com/blog/1452-new-github-pages-domain-github-io
http://homakov.blogspot.com/2013/03/hacking-github-with-webkit.html

Broadly, I'm not aware of any major site which assesses the subdomain threat as trivial or ignorable. Facebook serves from fbsbx.com ("sandbox"), Google serves from googleusercontent.com, and GitHub moved to github.io after publication of the fixation attack, for example.

Thank you for that explanation.

I read a bit more [1] and want to make sure I properly understand this:

• Using a different domain b.com for hosting static content for a.com prevents access to a.com's data by said files, even if they were accidentally linked to from somewhere within a.com? I.e. it can prevent privilege escalation / CSRF via <img src="b.com"/> or when making the user click <a href="b.com"/>?
• Scripts loaded from b.com and executed on a.com's site will still run within a.com's security context? Thus this technique is not effective against attacks embedding <script src="b.com"/> into a.com?
• Origin in this context refers to the window or website the user faces, not to the actual host of the content? I.e. the Origin of a script is the domain that contains <script src="b.com"/>, not the domain b.com?
• What applies to JavaScript also applies to Flash, Java, <audio/> and <video/> and other embeddable objects?
• CSP changes where content can be loaded from, but not within which security context it will operate? Thus it should be understood as an addition to, not as a requirement for user-content-domains, and is otherwise unrelated?

[1]: The MDN site about the Same-Origin Policy [2] was helpful, as were some german Wikipedia articles, among other sites.
[2]: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

Using a different domain b.com for hosting static content for a.com prevents access to a.com's data by said files, even if they were accidentally linked to from somewhere within a.com?

Mostly. There are (mostly-phishing, I think?) attacks with window.opener, and content on b.com may be able to read HTTP referrers. But b.com has no special privileges that aren't available to any site (including evil.com), so an attacker who can perform an attack using b.com can almost always just register their own evil.com and use that instead.

Scripts loaded from b.com and executed on a.com's site will still run within a.com's security context? Thus this technique is not effective against attacks embedding <script src="b.com"/> into a.com?

Correct. If an attacker can place a <script /> tag on a.com, they can load and execute JS from anywhere and it runs within the security context of a.com.

Origin in this context refers to the window or website the user faces, not to the actual host of the content? I.e. the Origin of a script is the domain that contains <script src="b.com"/>, not the domain b.com?

Yes. It's generally whatever's in the URL bar, not the domain the resource came from.

What applies to JavaScript also applies to Flash, Java, <audio/> and <video/> and other embeddable objects?

They have similar rules, but they probably aren't exactly the same (especially Flash/Java). I'm less familiar with the nuances of these content types.

CSP changes where content can be loaded from, but not within which security context it will operate?

Right. The big thing CSP does is block inline handlers (onclick="do_evil_stuff();" and <script>do_evil_stuff();</script>), which are traditionally easier for attackers to control than full-blown <script src="..."> tags, although it can also restrict domains that scripts can be loaded from. It doesn't affect the security context in which these scripts operate.

We don't currently implement CSP just because we haven't prioritized it, but plan to pursue it (see T4340). It's possible we might support three domains after that: a resource domain for CSS/JS, a user content domain for uploaded files, and a primary domain. After CSP, using the primary domain to serve CSS/JS would have the same security strength as using a third domain, but at the cost of reduced performance if you have a CDN available.