Aryeh Gregor wrote: > On Sun, Dec 28, 2008 at 1:40 PM, Ilmari Karonen <[email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
