Aryeh Gregor wrote:
On Sun, Dec 28, 2008 at 1:40 PM, Ilmari Karonen
<nospam(a)vyznev.net> wrote:
A simpler, though more heavy-handed, approach
might be simply to
disallow dashes in section anchors (presumably replacing them with
".2D"). This would leave any dashed IDs free for other uses.
That's pretty heavy-handed indeed. It's awfully arbitrary to demand
all our users use camel-case or underscores for their id's.
I was mostly thinking about enforcing this for section anchors only.
It seems to me there are (at least) three types of IDs that we would
rather not see conflict:
1. IDs generated and used by MediaWiki skins (and other parts?
extensions?).
2. IDs specified by users in wikitext (used either for site custom
JS/CSS or, since MediaWiki doesn't allow <a name="..."> in wikitext,
for
manually specifying link anchors).
3. Section anchors, which, for whatever reason known only to the W3C,
share a namespace with IDs.
Ideally, we'd like to keep all three apart, although the use of custom
IDs as link anchors (e.g. to preserve old anchor names when section
headings change) suggests that it should be at least possible to
manually specify IDs that lie in the part of the namespace normally used
for section anchors.
We already have code in the parser to prevent collisions _within_ type
3. Collisions within type 1 are bugs in MediaWiki, and should not
occur. We currently do absolutely nothing to stop IDs of type 2 from
colliding with either each other or with the other types.
it could lead to abuse. (Beansy question: are there
any places where
id's are used to do something in JavaScript, that people could exploit
by adding wikitext with those id's?)
You can grep wikibits.js and other files for getElementById. I don't
immediately see anything very serious. Yes, you can royally confuse
some scripts by creating elements with IDs like "toc", "column-one",
"p-cactions" or "mw-js-message", but those mostly just lead to some
missing or misplaced interface elements. Of course, there are plenty
more among user and site custom JS.
Hmmm... okay, assume someone is using a user script that adds interface
elements using addPortletLink(), AND assume those interface elements do
something potentially significant (like automatically editing a page)
without prompting for confirmation, AND assume a malicious user manages
to "hijack" the portlet ID, so that those interface elements get
inserted within the page content rather than in their proper places,
without the target user noticing, AND assume they further manage to hide
said misplaced interface elements with CSS AND also manage to convince
the target user to click on the hidden link.
We _could_ be looking at a potential clickjacking vulnerability here.
The obvious fix, while we still let duplicate IDs through, would be to
modify addPortletLink() so that it refuses to insert links within the
page content.
--
Ilmari Karonen