Last modified: 2011-03-13 18:06:29 UTC
This is a feature request to add a new mediawiki interface message page (ex [[mediawiki:headhtml]]) that inserts html somewhere between the <head> and </head> tags of a page.
<link title="Lastest News (RSS)" rel="alternate" href="http://feeds.feedburner.com/WikinewsLatestNews" type="application/rss+xml"/>
I don't believe this would add any additional security risks, as admins can already do quite a lot via the [[mediawiki:common.js]] and other messages that allow raw html.
Thanks for your consideration,
For some time we've been trying to move AWAY from any html being possible to include into the page. IMHO this is a step in the exact opposite direction.
These kind of additions are best left to extensions which already have proper ability to add links and other things to the head.
Oh, and yes it is a major security risk. JS is one thing, but allowing raw html in the header.
<meta http-equiv="refresh" content="1,http://en.wikipedla.org/" />
Then they could run a near exact copy of Wikipedia on the other site (fool users into thinking they are still on Wikipedia), and trick anyone into logging into the wiki, which could easily have a hacked login form that saves the password and then redirects back to Wikipedia.
Adding raw html is FAR more dangerous than allowing JS. Unlike JS, most browsers don't have an option to disable meta redirects. In fact, I only have that ability in FireFox because of the web developer toolbar.
We're moving away from having raw HTML in ordinary messages, but that's more for sanitization and privilege compartmentalization (e.g., a separate editjs right) than for security in a standard configuration.
That said, the specific request was serviced by introduction of a new config setting, I believe. Are there other proposed uses?
For a JS window.location = ... an administrator can disable JS then go and edit the JS message to remove it.
But for a meta tag. Disabling JS won't help at all. The administrator will have to hunt down an extension or other browser which is not affected by meta redirects just to remove it.
In fact, the number of people who can deal with a meta redirect is likely lower than those who can deal with a js redirect. The latter is fairly common, but to many admins the former may be quite unexpected.
If an admin is maliciously disabling the site, there are probably a number of other ways to do that. But I do take the point that this way is somewhat harder to fix. I can't really say more unless someone can come up with use cases that actually need this level of control for admins.
Provided the new $wgOverrideSiteFeed makes it past code review and goes live, it removes the use stated in this bug request. I'd want to see others before going forward. Lacking those, I'd second the call for WONTFIX.
Okay, marking WONTFIX until more suggested applications surface.