Page MenuHomePhabricator

CSS properties in wikitext can be abused to spam and make it difficult to remove them
Open, LowPublicFeature

Description

Author: newhen

Description:
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


Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/w/index.php?title=Alternate_reality_game&diff=124684781&oldid=124196403

Details

Reference
bz9526

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:41 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz9526.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

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.

newhen wrote:

I found it on a black hat seo site

newhen wrote:

and sorry I just found it im not a technical person

ayg wrote:

#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.

ayg wrote:

*** Bug 9655 has been marked as a duplicate of this bug. ***

ayg wrote:

*** Bug 10253 has been marked as a duplicate of this bug. ***

ayg wrote:

*** Bug 10253 has been marked as a duplicate of this bug. ***

fghielm wrote:

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...

(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.

Why not just disallow "position: absolute"? Are there any legitimate uses for it?

Lots of them. All articles which have some distintive image: Featured Articles, Good Articles, Geotagged articles...

ultrablue wrote:

(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.

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.

Bug 8679 related if not dupe.

az6024283313 wrote:

(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.

Chris, nobody tried to relate this bug with your problem (bug 14253). Please don't spam other bugs.

  • This bug has been marked as a duplicate of bug 8679 ***

ayg wrote:

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 #4's suggestion sounds like it could just be overridden with another !important with an even more aggressive z-index.

ayg wrote:

(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.

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.

ayg wrote:

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.)

I was assuming they were being set !important to avoid being overrided, but value limiting z-index is probably enough.

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.

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.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:01 AM
Aklapper removed a subscriber: wikibugs-l-list.