Last modified: 2014-11-17 10:35:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T10679, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 8679 - Consider blacklisting CSS attributes "z-index" and "position" in wiki text
Consider blacklisting CSS attributes "z-index" and "position" in wiki text
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low enhancement with 9 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 7303 14346 15066 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-17 20:05 UTC by Invalid Account
Modified: 2014-11-17 10:35 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Invalid Account 2007-01-17 20:05:31 UTC
I made a sample here http://en.wikipedia.org/w/index.php?
title=User:SakotGrimshine/buggycode&oldid=101395999

It's some crap Encyclopedia Dramatica is spamming on lots of wikis. I replaced the foul language in it 
with things like "buggycode" and I'd rather not link to their website. Try viewing the sample I gave in 
different web browsers as it gets worse depending on which used.

It would be good to fix page rendering so this code doesn't work.
Comment 1 Invalid Account 2007-01-17 20:06:09 UTC
This should be all on one line:

http://en.wikipedia.org/w/index.php?title=User:SakotGrimshine/buggycode&oldid=101395999

Comment 2 Rob Church 2007-01-17 20:07:59 UTC
This is quite a common form of vandalism, and I suppose we could block it with
$wgSpamRegex on Wikimedia sites, though it would just encourage further variants.

Two solutions here; either continue to revert it, or we could consider
blacklisting further CSS attributes, such as z-index etc.
Comment 3 Antoine "hashar" Musso (WMF) 2007-01-17 20:08:59 UTC
Should we disable the value 'position:fixed' in the sanitizer ?
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-01-26 00:04:43 UTC
There's not really any reason to allow position: fixed in article content, probably, but this could 
easily be just as disruptive with position: absolute or relative or whatever.  Any of those could 
overwrite stuff outside the article box.  But absolute and relative positioning are standard, useful 
CSS properties.  Silly vandalism like this can be dealt with easily enough.  I suggest WONTFIX.
Comment 5 Invalid Account 2007-02-01 02:01:16 UTC
People seem to use this or some other funky HMTL code to give themselves messed up user and talk 
pages with buttons and links outside the normal text window.
Comment 6 Titoxd 2007-04-22 08:04:27 UTC
Well, this would break [[Template:Featured article]],
[[Template:Pp-semi-protected]], [[Template:Spoken]], and others, to name a few.
Comment 7 Mark Ryan 2007-04-22 14:45:14 UTC
... So build-in functionality to make those sorts of icons in the top right of 
articles. This functionality needs to be removed. The potential for abuse is 
too great; I'm surprised it hasn't been used maliciously yet.

See, for example, http://en.wikipedia.org/wiki/User:Mark/temp

The form at the destination there just leads right back to Wikipedia, but it 
could just as easily be used to silently capture usernames and passwords for 
unspecified future abuse.
Comment 8 Gregory Maxwell 2007-04-22 17:13:02 UTC
Come now, separation of code and presentation would be good.  At a minimum we
could allow the introduction of fancy positioning stuff via items in MediaWiki
namespace... this would preserve the operation of sane site wide things, and
prevent the introduction of ugly one-offs that tend to have poor usability or
violate the principle of least surprise.
Comment 9 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-22 20:17:35 UTC
Take a look at, for instance, the link created by ImageMap to the source image's
page.  That uses absolute positioning.  Yes, separating content and markup is
good, but it's not really practical at present while permitting reasonably
flexible formatting, since it's so much slower to have to get sysops involved. 
Banning these properties entirely is overkill.  What should be prevented is
overlaying anything on top of interface elements; that's bug 9526, and should be
possible to accomplish without resorting to this.
Comment 10 Mark Ryan 2007-04-23 02:08:16 UTC
Would there be any way of preventing such absolute positioning from putting 
stuff beyond the left hand side of the article area, or above the bottom of the 
tabs? The main concern is preventing all those links from being hijacked. 
People using this for horrendous unaesthetic user pages is a secondary matter.
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-23 13:54:42 UTC
That's exactly my point.  See bug 9526 for a proposed solution.
Comment 12 Brion Vibber 2008-05-30 17:13:39 UTC
*** Bug 14346 has been marked as a duplicate of this bug. ***
Comment 13 Brion Vibber 2008-05-30 17:13:57 UTC
*** Bug 9526 has been marked as a duplicate of this bug. ***
Comment 14 Brion Vibber 2008-05-30 17:14:21 UTC
*** Bug 7303 has been marked as a duplicate of this bug. ***
Comment 15 Richard Jenkins 2008-05-30 17:22:42 UTC
May also be a good idea to blacklist the 'overflow' attrib. as well. See Bug 14346 for examples of disruption using this attribute.
Comment 16 Brion Vibber 2008-08-07 18:09:49 UTC
*** Bug 15066 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links