I think you should be able to access document.styleSheets but not to its items?

correct cssRules and the other elements that are cross domain protected.

I think this could be solved by simply adding the header:

Access-Control-Allow-Origin: *

to all bits.wikimedia.org requests ? Unless we have non-public data that comes from that server, but I doubt that such data uses the bits server, because it would not be cache-able.

Geoiplookup has a similar security issue I guess, but that does carry sensitive data, and thus needs specific Origin targeting (API has this I believe).

Giving this to Ashar so he can poke his head in.

Acknowledging assignment. I have to:

• learn about access control
• figure out what exactly need to be changed on the cluster
• get that reviewed
• do the change and test it :-)

Ashar, don't forget to have in list assessing in what ways could a given configuration be abused.

Also, the code in skins/common/diff.js accesses stylesheets using js on some browsers, is said code currently broken because of this?

That code is only for really old gecko browsers. 20021130 november 2002. those browsers didn't have cross domain protection yet.

Un assigning myself. I did not looked at that one for 7 months and I am not going to fix it anytime soon anyway.

(changing bug to match search phrase "CORS")

(In reply to comment #3)

I think this could be solved by simply adding the header:

Access-Control-Allow-Origin: *

to all bits.wikimedia.org requests ? Unless we have non-public data that comes
from that server, but I doubt that such data uses the bits server, because it
would not be cache-able.

Geoiplookup has a similar security issue I guess, but that does carry sensitive
data, and thus needs specific Origin targeting (API has this I believe).

bits.wikimedia.org should be restricted the same way as the API.

Though on second thought:

• /geoiplookup
  • Easily worked around, there are many public IP-to-location systems out there. The IP itself is not easily retrievable except with another domain available. We probably shouldn't be that domain.

• /../load.php: Modules can be private (e.g. user.options contains preferences), however these are already protected in load.php (e.g. try https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&modules=user.options&only=scripts). Private modules can only be loaded from server output.

(In reply to comment #11)

• /../load.php: Modules can be private (e.g. user.options contains

preferences), however these are already protected in load.php (e.g. try
https://bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&modules=user.options&only=scripts).
Private modules can only be loaded from server output.

Most of what load.php serves is JavaScript, which doesn't need CORS. The only thing I can see load.php remotely needing CORS for is CSS in only=styles requests. We can safely serve ACAO:* for those from within ResourceLoader. All other load.php requests should not use CORS. Geoiplookup also should not use CORS.

Static resources can be served with ACAO:* as well.

Related URL: https://gerrit.wikimedia.org/r/60200 (Gerrit Change I8e05c13ae1a1589fd120d5c439b1a7128ce2b659)

(moving bug from Wikimedia site requests to MediaWiki core)

Though I don't see a problem with this change (I8e05c13ae1a1), could you provide one or more use cases for accessing document.styleSheets in a MediaWiki context (just for future reference, I can imagine many use cases, but I'd like to know what TheDJ was doing).

Not blocking merge however, just curiosity.

Personally, I was flipping the media attributes of stylerules, to manipulate the output of printing. My script allowed you to print 'what you see' for instance, instead of always printing with the 'print style'. This was a incidental request by users by en.wp users. There have been a few other cases (dynamically removing style rules when you no longer need them as a script was another one if I remember correctly).

My script (with this function currently disabled because it isn't working without CORS): [[User:TheDJ/printdialog]]