Last modified: 2013-03-25 15:25:07 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 9526 - CSS properties in wikitext can be abused to spam and make it difficult to remove them
CSS properties in wikitext can be abused to spam and make it difficult to rem...
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low enhancement with 8 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/w/index.php?t...
:
: 9655 10253 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-08 04:45 UTC by lol lol
Modified: 2013-03-25 15:25 UTC (History)
9 users (show)

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


Attachments

Description lol lol 2007-04-08 04:45:37 UTC
adding this to a page 
<p style="font-size: 50000px; left: -50px; width: 100%; position: absolute; top:
-50px; height: 100%; font-color: transparent">[http://www.yourlink.com/]</p>

Now whenever a visitor clicks on a link, it will be sent automatically to your site
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-08 04:54:52 UTC
It takes a certain kind of evil genius to think that up.  What kind of approach should we take 
here?  No one of the attributes is bannable by itself.  In fact, that exact markup would be 
totally legitimate within any box positioned non-statically.  So how to handle that?  We'll need 
to make our CSS handling a *lot* more intelligent to be able to deal with it without collateral 
damage.

Maybe we could just make #column-content position: relative, set #column-one's z-index high (say, 
50), and then ban z-indexes higher than our selected number.  That should make it impossible to 
overwrite anything outside the article using CSS.  Thoughts?  I agree that this is very serious in 
terms of abuse potential, I'm leaving priority and severity alone.
Comment 2 lol lol 2007-04-08 06:47:17 UTC
I found it on a black hat seo site 
Comment 3 lol lol 2007-04-08 06:48:19 UTC
and sorry I just found it im not a technical person
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-12 04:27:15 UTC
#column-one a { position: relative; z-index: 50 ! important; } works to fix it as a quick hack in 
Common.css, but it degrades layout slightly due to the z-index-based positioning of Monobook.  It 
should be easily adaptable, however, to not damage layout, and combined with an extra z-index 
cleaner in Sanitizer.php, it should make it impossible to damage layout using in-article CSS.  It 
should not prevent any templates whatsoever unless they attempt to overlay interface links, which 
they should never do.  It may require some to be revised in the worst case to account for the 
changed z-index, but I think I can avoid that.

Unfortunately, I'm strapped for time and can't make this a high priority.  If someone else can work 
on this a bit that would be great.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-04-22 03:03:07 UTC
*** Bug 9655 has been marked as a duplicate of this bug. ***
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-14 22:06:04 UTC
*** Bug 10253 has been marked as a duplicate of this bug. ***
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-14 23:39:16 UTC
*** Bug 10253 has been marked as a duplicate of this bug. ***
Comment 8 Franz_aRTiglio 2007-06-15 10:59:27 UTC
Sorry for posting a duplicate bug, btw I think can be considered invalid a font size bigger than X, or maybe by blocking any transparent font, so any spam-link added using this method will cause the whole added paragraph to be ignored...

Comment 9 Danny B. 2007-07-18 11:16:26 UTC
(In reply to comment #8)
> ... I think can be considered invalid a font size bigger than X...

It can be overriden by multiple tags with relative sizes.


Comment 10 Thomas Bleher 2008-01-24 20:11:20 UTC
Why not just disallow "position: absolute"? Are there any legitimate uses for it?
Comment 11 Platonides 2008-01-24 21:25:39 UTC
Lots of them. All articles which have some distintive image: Featured Articles, Good Articles, Geotagged articles...
Comment 12 Mark Ryan 2008-01-25 00:16:12 UTC
(In reply to comment #11)
> Lots of them. All articles which have some distintive image: Featured Articles,
> Good Articles, Geotagged articles...

That's a weak argument. If that functionality is so core to the encyclopedia the developers could quite readily invent a new markup for placing an icon with a link at the top right of a page.
Comment 13 Danny B. 2008-01-25 04:49:45 UTC
Absolute positioning is used on maps with dots showing such place on them as well. I also saw some template with compass rose.

Regarding topic saying difficult to remove - well, it depends what is considered as difficult - as far as your wiki keyboard shortcuts are enabled, you can easily get into the source and remove the malicious code. If no shortcuts available/supported, you can set action=edit parameter in URL. You can also set different skin either via preferences or useskin= parameter in URL which will cause different behavior of the bad code. In a really worst case (I can't actually imagine any) you can turn off the stylesheets in your browser temporarily to get into the edit page. There is also chance to use undo/rollback link from the diff view. So removing is definitely not as difficult as it is being presented here.

Limiting of CSS would bring more negatives than positives and break lot of current functional solutions. If this was on me I'd either mark this invalid or wontfix. There are no reasonable benefits of any restriction. On top of it, one of the current restrictions - background image - is already way so annoying and should be less restrictive, however, that's question for another bug.
Comment 14 Danny B. 2008-01-25 04:58:17 UTC
Bug 8679 related if not dupe.
Comment 15 Chris 2008-05-24 22:04:21 UTC
(In reply to comment #0)
> adding this to a page 
> <p style="font-size: 50000px; left: -50px; width: 100%; position: absolute; top:
> -50px; height: 100%; font-color: transparent">[http://www.yourlink.com/]</p>
> Now whenever a visitor clicks on a link, it will be sent automatically to your site

This does not apply to me. I am not editing a page!!! I just wanna see the main page in normal fonts.
Comment 16 Platonides 2008-05-25 12:00:48 UTC
Chris, nobody tried to relate this bug with your problem (bug 14253). Please don't spam other bugs.
Comment 17 Brion Vibber 2008-05-30 17:13:57 UTC

*** This bug has been marked as a duplicate of bug 8679 ***
Comment 18 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-05-30 17:19:30 UTC
This is not a dupe of bug 8679; this is an alternative to it, or a generalization of it.  See the comments at the end of bug 8679.  I would prefer to close that as WONTFIX, or dupe it to this.  See comment #4 here for a way to possibly fix this without having to ban anything.
Comment 19 Brion Vibber 2008-05-30 19:37:58 UTC
Comment #4's suggestion sounds like it could just be overridden with another !important with an even more aggressive z-index.
Comment 20 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-05-30 19:58:13 UTC
(In reply to comment #19)
> Comment #4's suggestion sounds like it could just be overridden with another
> !important with an even more aggressive z-index.

You're missing the "combined with an extra z-index cleaner in Sanitizer.php" part of that comment.  There's no legitimate reason for users to need to set their z-index above, say, 999, if the interface z-index is 1000.
Comment 21 Platonides 2008-05-30 20:06:23 UTC
> There's no legitimate reason for users to need to set
> their z-index above, say, 999, if the interface z-index is 1000.

Nor i see the need to set !important the z-index rules.

Comment 22 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-05-30 20:08:49 UTC
No, that's fine.  Actually !important has no bearing on this at all, since the elements in question will normally have no z-index pre-specified, and anyway inline style overrides any specification that might exist unless that specification uses !important.  (In my example specification I used !important, but only because it was in Monobook.css; if it were in main.css in place of the current rule that would be unnecessary, if it's not unnecessary in any event.)
Comment 23 Platonides 2008-05-30 20:13:11 UTC
I was assuming they were being set !important to avoid being overrided, but value limiting z-index is probably enough.
Comment 24 Helder 2012-03-29 21:41:39 UTC
Marking as WORKSFORME for now since I wasn't able to reproduce it on
https://en.wikipedia.org/?oldid=484602370
using Google Chrome 18 and Firefox 11.0.
Please reopen if it is still reproducible for someone else.
Comment 25 Platonides 2012-03-29 22:20:06 UTC
I can reproduce it using <div> instead of <p>, but the font-color: transparent  doesn't seem to be applied, so you can tell that there's something going on.
However, that can be worked around with little problem.

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


Navigation
Links