https://bugzilla.wikimedia.org/show_bug.cgi?id=40679
--- Comment #18 from Krinkle <[email protected]> 2012-10-02 21:42:24 UTC --- (In reply to comment #17) > (In reply to comment #12) > > How is that a security vulnerability? wfExpandUrl is by no means a security > > measure, and PROTO_HTTPS is nowhere documented nor intended to generate > > https > > urls. The argument to wfExpandUrl means the "preferred protocol if there > > isn't > > any", not the "protocol that will be used in the url". > > > > To put it bluntly, if something relies on it returning on https, then it is > > plain wrong. If that is the topic of this bug, then afaik we can close this > > as > > an invalid bug. > > > > Please describe (or show) the code that is passing PROTO_HTTPS to > > wfExpandUrl. > > You may be right that something relying on wfExpandUrl to return HTTPS is > wrong, but there are still many places in the core that do this exactly. Like > Chris said above, loading default MediaWiki from Git and then going over to > HTTPS causes all resources to be loaded over an insecure connection. Not only > is this a usability problem since Chrome will refuse to load those resources, > but it is a security vulnerability because you now have load.php and api.php > requests going over an insecure connection, opening up MediaWiki to JS > injections and leakage of sensitive information. Just because wfExpandUrl > isn't > a security measure does not mean it cannot cause security problems. This is imho not a bug. It is expected (and imho acceptable) behaviour. For the same reason that we include the configured hostname, we include the configured protocol. Though I agree the following comparison does not relate to SSL, the fact that your issue above does is imho an unrelated coincidence and result of misconfiguration on the administrators part. Imagine I set up a wiki with wgServer='http://example.org' and then I set up http://localhost/ pointing to the same server. Oh noes, when I access over localhost everything points to example.org. That's not a mediawiki bug, but a configuration issue! Either redirect one to the other, set them up as 2 wikis (e.g. a if/else or switch construct by hostname and configure wgServer and/or wgDBname based on that) or (recommended) make sure the configuration is properly set up for either scenario. Give me one good reason why anything should work on https://wiki.example.org/ if the wiki is configured and "told" by the administrator that it is served from http://wiki.example.org. Fix your configuration? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
