https://bugzilla.wikimedia.org/show_bug.cgi?id=40679
--- Comment #17 from Tyler Romeo <[email protected]> 2012-10-02 17:31:27 UTC --- (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. -- 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
