I think the whole point of phab.wmfusercontent.org was a security thing to begin with, so that scripts/content/whatever uploaded to phab by users wouldn't be considered by browsers to be same-domain origin as the real phabricator.wikimedia.org stuff.

We should add some content at https://wmfusercontent.org then to state that.

BBlack: why?

In T104730#1425725, @BBlack wrote:

I think the whole point of phab.wmfusercontent.org was a security thing to begin with, so that scripts/content/whatever uploaded to phab by users wouldn't be considered by browsers to be same-domain origin as the real phabricator.wikimedia.org stuff.

That is correct. @Mike_Peel, an easy example is SVG files, which can contain javascript, and interact with the domain where it's served from as you if you view it. If we served them from the main phabricator.wikimedia.org domain, we would have to disallow uploading all svgs (and do a much better job filtering other formats).

Or they could be uploaded to commons, which copes with svgs just fine?

@Mike_Peel To do development stuff, sometimes we have to have files of various types that could be dangerous. For example, svgs that take over your account and do malicious things on your behalf are not allowed on commons (But normally people don't upload malicious svgs to pahb. Usually its not malicious files. We just need the ability to upload any sort of file into phab if we need it for discussing bugs. Most uploaded files are patch files).

I have no idea why js is coming from that domain though, that seems odd. I see no reason for non-uploaded content to come from that domain. And I agree that there should be an intro page at the root of that domain explaning what it is. https://upload.wikimedia.org/ has one...

What kind of Javascript do you see loaded from wmfusercontent.org? Could you give an example?

I see multiple resources loaded from there myself. It is unfortunate that we're mixing user-uploaded content with Phabricator's own assets loaded in every page in that domain. Ideally, these would be separated from each other with the former being served from Phabricator's canonical domain, but I'm not sure how feasible that is.

All that said:

Alternatively, the domain should redirect to a valid website, and/or explicitly explain that it is owned by the WMF.

I don't understand the logic behing this — what appears to be a "valid website" would not really give you any guarantees that it is operated by the WMF. If this was a phishing domain that we did not own, the adversary in question could just as well set up a web server themselves.

Just FYI (I am not worried about this), the ones I can see being loaded on a sample uncached request to this very same ticket:

https://phab.wmfusercontent.org/res/phabricator/3010e992/rsrc/externals/javelin/core/init.js
https://phab.wmfusercontent.org/res/phabricator/3ec6a6d5/maniphest.pkg.js
https://phab.wmfusercontent.org/res/phabricator/a590b451/core.pkg.js
https://phab.wmfusercontent.org/res/phabricator/ebef29b1/differential.pkg.js

Alternatively, the domain should redirect to a valid website

That aspect is kind of covered in T104735: (www.)wmfusercontent.org should respond to HTTP

Yeah it sounds to me like these are assets that should be moved to the primary phabricator site...

The Phabricator's res dir contains generated files based on either the phabricator.base-uri or security.alternate-file-domain.

I think the assets are served from the separate domain in order to allow them to be more easily separated from dynamically generated content. Phabricator JavaScript is mostly static, only changing with an update, not per-request. So the idea is to allow more aggressive cache policy on the entire alternate-file-domain while also separating dangerous files so that we get the benefit of the browsers' cross-domain-policy restrictions.

As @faidon mentioned, it would be better to have a separate setting for phabricator's own static content and our user-uploaded content. I'm not sure if there is currently a way to separate this.

The dependencies I see when accessing phabricator are (including images, CSS and Javascript, looking at the main page):

<link rel="apple-touch-icon" href="https://phab.wmfusercontent.org/res/phabricator/ecdef672/rsrc/favicons/apple-touch-icon-76x76.png" />
<link rel="apple-touch-icon" sizes="120x120" href="https://phab.wmfusercontent.org/res/phabricator/43742962/rsrc/favicons/apple-touch-icon-120x120.png" />
<link rel="apple-touch-icon" sizes="152x152" href="https://phab.wmfusercontent.org/res/phabricator/669eaec3/rsrc/favicons/apple-touch-icon-152x152.png" /><meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" /><meta name="referrer" content="never" /><script type="text/javascript">(top == self) || top.location.replace(self.location.href);window.DEV=0;</script><link rel="stylesheet" type="text/css" href="https://phab.wmfusercontent.org/res/phabricator/5630d89f/core.pkg.css" /><link rel="stylesheet" type="text/css" href="https://phab.wmfusercontent.org/res/phabricator/564bfc7a/rsrc/css/font/font-lato.css" /><link rel="stylesheet" type="text/css" href="https://phab.wmfusercontent.org/res/phabricator/cb8ae7ad/rsrc/css/phui/phui-fontkit.css" /><link rel="stylesheet" type="text/css" href="https://phab.wmfusercontent.org/res/phabricator/cda88637/rsrc/css/font/font-roboto-slab.css" /><link rel="stylesheet" type="text/css" href="https://phab.wmfusercontent.org/res/phabricator/6b451f24/rsrc/css/application/base/phui-theme.css" /><link rel="stylesheet" type="text/css" href="https://phab.wmfusercontent.org/res/phabricator/37e05e50/rsrc/css/sprite-main-header.css" /><script type="text/javascript" src="https://phab.wmfusercontent.org/res/phabricator/3010e992/rsrc/externals/javelin/core/init.js"></script></head>

<span class="phabricator-core-menu-icon phabricator-core-menu-profile-image" style="background-image: url(https://phab.wmfusercontent.org/res/phabricator/3eb28cd9/rsrc/image/avatar.png)">

<script type="text/javascript" src="https://phab.wmfusercontent.org/res/phabricator/a590b451/core.pkg.js"></script><script type="text/javascript" src="https://phab.wmfusercontent.org/res/phabricator/ebef29b1/differential.pkg.js"></script>

"lightbox-attachments":[{"defaultImageUri":"https:\/\/phab.wmfusercontent.org\/res\/phabricator\/45fe1c60\/rsrc\/image\/icon\/fatcow\/document_black.png",

I don't understand the logic behing this — what appears to be a "valid website" would not really give you any guarantees that it is operated by the WMF. If this was a phishing domain that we did not own, the adversary in question could just as well set up a web server themselves.

That's true, but it would give a clearer indication than one that doesn't respond at all. Ideally I guess it should have a signed SSL certificate too, in order to better validate its ownership.

In T104730#1430255, @Mike_Peel wrote:

I don't understand the logic behing this — what appears to be a "valid website" would not really give you any guarantees that it is operated by the WMF. If this was a phishing domain that we did not own, the adversary in question could just as well set up a web server themselves.

That's true, but it would give a clearer indication than one that doesn't respond at all. Ideally I guess it should have a signed SSL certificate too, in order to better validate its ownership.

We're digressing a bit but if someone else would own wmfusercontent.org, they would be able to issue a signed SSL certificate as well. They wouldn't be able to issue an OV one for Wikimedia, but OV & DV are hard to tell apart from each other. They also wouldn't be able to issue an EV, that says "Wikimedia Foundation, Inc." but we generally do not issue EV certificates for anything but payments (for various reasons). In any case, I'm not sure what the perceived threat is here :)

We're digressing a bit but if someone else would own wmfusercontent.org, they would be able to issue a signed SSL certificate as well. They wouldn't be able to issue an OV one for Wikimedia, but OV & DV are hard to tell apart from each other. They also wouldn't be able to issue an EV, that says "Wikimedia Foundation, Inc." but we generally do not issue EV certificates for anything but payments (for various reasons). In any case, I'm not sure what the perceived threat is here :)

At the very least it makes it more difficult to do, and easier to spot. ;-) But, thinking about it, an obvious cross-check would be for the domain to say "this is owned by the WIkimedia Foundation", and to link to a Wikimedia Foundation page that says "we also own this domain". These are just idle thoughts, though: I'm sure that there are standard ways of making domain ownership clearer in a standard way. But the main issues are that it isn't user-friendly to not have a splash page on the domain; and that JS shouldn't really be served from it.

In T104730#1429135, @faidon wrote:

What kind of Javascript do you see loaded from wmfusercontent.org? Could you give an example?

I see multiple resources loaded from there myself. It is unfortunate that we're mixing user-uploaded content with Phabricator's own assets loaded in every page in that domain. Ideally, these would be separated from each other with the former being served from Phabricator's canonical domain, but I'm not sure how feasible that is.

In T104730#1429586, @BBlack wrote:

Yeah it sounds to me like these are assets that should be moved to the primary phabricator site...

This was previously requested as T670 and declined (with very little rationale).

To quote my own comment from there (which didn't get a response):

In T670#1007026, @matmarex wrote:

Um, this definitely looks like some kind of misconfiguration to me. wmfusercontent.org, as the name says, is presumably intended to be used for user-uploaded content like task attachments, with the different TLD serving to make it impossible to steal cookies from the real site using uploaded HTML attachments, and the like – however, currently it is used both for these and for built-in Phabricator styles and scripts. This is not insecure in any way, of course, but it does cause spidey senses to tingle.

If we want to serve static content from a separate domain which has no cookies set (which is reasonable and possibly a performance improvement in some cases), then I think we should use phabricator-static.wikimedia.org, or something like that, and not reuse phab.wmfusercontent.org.

@matmarex: The reason for our current setup is simply that it was the only convenient way to do it. We don't have a dedicated phabricator team and it's simply not that important since it isn't a security concern.

Phabricator is set up to serve files this way, altering it is inconvenient and would require a lot of effort without much objective benefit.

Then it should be fixed, the dependency/separation needs to stay for
security reasons, as stated by our security team.

The lack of style issue earlier today is relatively-unrelated (cert expiry issue, but the impact would've been smaller if this separation issue here had already been resolved). It would be nice if phab could serve its own static content from the primary domain rather than the security alt-domain, but AFAICS upstream phabricator's code/config simply doesn't allow for that at present.

Phabricator has been temporarily fixed.

Yes, separation should stay @greg. I am not suggesting merging both domains, but report and/or fix the load of phabricator's own js and css. T104730#1430156 comment would seem to be the way to go.

I think the purpose if this ticket should be clarified in the description (as agreed by ops and releng); there are multiple opinions floated here.

The original intention of this ticket is already being discussed on T104735, that is no more relevant here. We need to update the ticket to clarify that this ticket is about:

• Putting phabricator JS/CSS on its main domain, user content on wmfusercontent.org

or

• Putting phabricator JS/CSS on (for example) phab-static.wikimedia.org and user content on wmfusercontent.org

Not doing it myself because I am not 100% sure this is the agreed decision?

In T104730#1640940, @jcrespo wrote:

The original intention of this ticket is already being discussed on T104735, that is no more relevant here. We need to update the ticket to clarify that this ticket is about:

• Putting phabricator JS/CSS on its main domain, user content on wmfusercontent.org

or

• Putting phabricator JS/CSS on (for example) phab-static.wikimedia.org and user content on wmfusercontent.org

Not doing it myself because I am not 100% sure this is the agreed decision?

Yes, basically once you separate out the T104735 concern, the only thing left to talk about here is the first of your two options. The second one doesn't seem useful in the net. However, we know that phab can't actually be configured for either of those options without some upstream code changes, so it's kind of a non-starter unless someone wants to spend time making that happen. It's a design issue, but it's not a huge one.

@BBlack, then maybe report it upstream and close it. Monitor if it can be done in the future.

I'm removing the security tag on this bug.

My personal opinion is this should be declined. But either way its not a security issue, so I'm removing the security tag.