Hmmm.

On one hand, I kind of feel like its a browser issue - Should they really allow globally routed internet apps make requests to private IP space intranet app. But that's probably kind of impossible.

I think that people who want private version of mediawiki should ensure that anon users do not have read rights.

That said, maybe we should disable origin=* if $wgServer is a private IP address.

In T210791#4787819, @Bawolff wrote:

On one hand, I kind of feel like its a browser issue - Should they really allow globally routed internet apps make requests to private IP space intranet app. But that's probably kind of impossible.

That's the purpose of the same-origin policy. Our software is providing an exception to that policy.

In fact, we're allowing the client to make that exception, which makes the setting pointless. If we set Access-Control-Allow-Origin: * on every request, we'd have the same thing we have now (as far as I can tell).

I for one, am in favor of doing that, but regardless, the client should not be allowed to make an exception to the same-origin policy for itself.

In T210791#4788124, @dbarratt wrote:

In T210791#4787819, @Bawolff wrote:

On one hand, I kind of feel like its a browser issue - Should they really allow globally routed internet apps make requests to private IP space intranet app. But that's probably kind of impossible.

That's the purpose of the same-origin policy. Our software is providing an exception to that policy.

I think its debatable if access control to intranet sites is really in the threat model of the same origin policy (for example, consider https://en.wikipedia.org/wiki/DNS_rebinding attacks more generally). [Of course, at some point that doesn't matter. We have to deal with the consequences regardless]

I would also say that configuring mediawiki to allow full read access without logging in, and then try and restrict mediawiki solely by placing it on an internal network, is probably not exactly best practise. There are probably other attacks possible here even without CORS (e.g. Cause mediawiki to do something with a secret via a cross origin write (SOP only prevents reads not writes), and then try and leak it through some sort of caching side channel. I'm sure a dedicated attacker could find some way to do this in a scenario when all users have full read access but MW is in private network).

In T210791#4788142, @Bawolff wrote:

I think its debatable if access control to intranet sites is really in the threat model of the same origin policy (for example, consider https://en.wikipedia.org/wiki/DNS_rebinding attacks more generally). [Of course, at some point that doesn't matter. We have to deal with the consequences regardless]

I didn't think it was, but after a long (albeit, heated) discussion it seems like that is exactly the threat model of the same-origin policy. At least for credential-less cross-origin requests, but the browser will not send credentials cross-origin, so it is a matter of intranet sites.

I didn't think it was, but after a long (albeit, heated) discussion it seems like that is exactly the threat model of the same-origin policy. At least for credential-less cross-origin requests, but the browser will not send credentials cross-origin, so it is a matter of intranet sites.

I think that thread is more suggesting, that changing the way same origin policy works would be an absolute nightmare, and that intranet sites have started to depend on this behaviour.

All I'm saying, is that the same origin policy is somewhat weak for protecting this usecase (The enforcement of SOP is much weaker then the general assumption that the private IP space will prevent all external access), and setting up mediawiki in this way is probably mildly problematic

On the public internet, cookies are the most common way to manage state. But there are probably sites that do other things.

But this all is beside the point.

In T210791#4788142, @Bawolff wrote:

I would also say that configuring mediawiki to allow full read access without logging in, and then try and restrict mediawiki solely by placing it on an internal network, is probably not exactly best practise. There are probably other attacks possible here even without CORS

e.g. jsonp.

I'm inclined to decline this task.

I mean I think that's fine to say that we don't support open MediaWiki installs on private intranets (without some sort of other authorization).

Honestly, I don't think we should. :) So feel free to close.