Last modified: 2011-11-18 03:17:09 UTC
r62546 of MediaWiki implemented Cross-Origin Resource Sharing (CORS) in the WikiMedia API. This allows JavaScript to call the API from designated (or all) external websites. CORS is now enabled on the recent releases of all major web-browsers. The upshot of this is that the major browsers have ceased to support JavaScript calls that are not CORS compliant. The English-language Wikipedia is using r64051. Can we add toolserver.org to the "white list" of websites allowed to make JavaScript calls to the English-language Wikipedia? This request has been raised on-site at the Village Pump. No concerns were raised and it was commented that it seemed like no-one would object. When CORS was feature requested this request was also raised but naturally postponed until CORS support was live (https://bugzilla.wikimedia.org/show_bug.cgi?id=19907). The change requires adding '*.toolserver.org' to the wgCrossSiteAJAXdomains array in includes/DefaultSettings.php.
... actually both '*.toolserver.org' and 'toolserver.org' would need to be added to the array since not all tools run on a subdomain.
This would allow *.toolserver.org to bypass CSRF checks, with escalation to full account compromise, say by editing the user's *.js subpages. I thought the whole point of using a separate 2nd level domain was to avoid cookie sharing with *.wikimedia.org. I assume toolserver.org is full of exploitable XSS vulnerabilities which could be used as a proxy to launch an attack against a Wikimedia user account from an external malicious site. I bet I could find one in 5 minutes. Suggest WONTFIX.
That's disappointing. An possible alternative would be to change how the Access-Control-Allow-Credentials header is sent in api.php. In CORS the Access-Control-Allow-Origin header allows cross-domain scripting, but the Access-Control-Allow-Credentials allows those scripts to share credentials and cookies. Setting Access-Control-Allow-Credentials to false (as opposed to true, which it is now) would allow JavaScript on the external server to connect to the API but not have access to cookies (i.e. could not log in).
Based on the [En.Wikipedia] Village Pump discussion[1], this is so java-script can use the users authentication to do editing and such? I thought the ToolServer already had rules against tools and such asking for/using a users authentication access on a WMF wiki[2] which is this not what the change would allow? As pointed out by Tim, what other security issues would this bring up.... Because there are alot of tools on the toolserver and not sure all of them would be security checked/reviewed to ensure there are no issues on that front. [1]. http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Re-enabling_JavaScript_access_to_the_API [2]. https://wiki.toolserver.org/view/Rules#Terms_of_Use (Point 8)
(In reply to comment #4) > As pointed out by Tim, what other security issues would this bring up.... > Because there are alot of tools on the toolserver and not sure all of them > would be security checked/reviewed to ensure there are no issues on that front. > Exactly. Since almost anyone can get a toolserver account and host almost anything (even if it's against the rules, it'll take some time for toolserver admins to notice and take it off), toolserver.org is not fundamentally different from other non-WMF domains and should therefore be subject to the same security measures.
