Last modified: 2008-03-24 21:01:28 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 3243 - & in page titles is not appropriately escaped in various cases
& in page titles is not appropriately escaped in various cases
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.6.x
All All
: Normal trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review, testme
Depends on:
Blocks: html
  Show dependency treegraph
 
Reported: 2005-08-23 19:58 UTC by David Benbennick
Modified: 2008-03-24 21:01 UTC (History)
4 users (show)

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


Attachments
Patch to fix 3, 4, 5, 6, 7, and update Language.php slightly (4.64 KB, patch)
2005-08-29 03:09 UTC, David Benbennick
Details
also fix 2 and 13 (6.19 KB, patch)
2005-08-29 03:56 UTC, David Benbennick
Details
Fix 10 and 12. 1, 9, 11, and 15 remain (8.77 KB, patch)
2005-08-29 05:09 UTC, David Benbennick
Details
better fix for point 10, {{PAGENAME}} sanitization (8.91 KB, patch)
2005-08-29 19:00 UTC, David Benbennick
Details
better fix for point 10, also fix 11 and 15 (11.91 KB, patch)
2005-08-29 20:05 UTC, David Benbennick
Details

Description David Benbennick 2005-08-23 19:58:49 UTC
Page titles are not HTML-sanitized in various cases.  Since page titles can have
& in them, this leads to various minor bugs.  I'd like to record all I can find
here.

1) Neither [{{SERVER}}{{localurl:{{PAGENAME}}}}] nor
[{{SERVER}}{{localurl:{{PAGENAMEE}}] works for the page entitled <

2) Special:Watchlist/edit appears to pass page titles literally.  If you're
watching [[&lt;]], the list shows < with no link.

3) action=unwatch for [[&lt;]] displays "The page "<" has been removed from your
watchlist."  The variable $1 has not been escaped in [[MediaWiki:Removedwatchtext]].

4) The same goes for [[MediaWiki:Addedwatchtext]].

5) And [[MediaWiki:Deletedtext]], parameter $1.

6) And [[MediaWiki:Undeletedtext]]

7) [[Special:Movepage/%26lt%3B]] displays "Move page: <", not "Move page: &lt;"

8) Although the "Confirm delete" page correctly shows (Deleting "&lt;), the
"Confirm protection" page shows (Protecting "<").  (The same goes for "Confirm
unprotection".)

9) [[Special:Log]] doesn't accept &lt; in the Title field.  See
http://en.wikipedia.org/w/index.php?title=Special%3ALog&page=%26lt%3B

9.1) The same bug shows up when undeleting [[&lt;]].  Instead of displaying the
deletion log for the page, it displays the entire deletion log.

10) A new variable is needed, like {{PAGENAME}} and {{PAGENAMEE}}, that gives an
HTML-sanitized version of the page title.  At the moment, there's no good way to
fix [[MediaWiki:Newarticletext]], as it displays for [[&lt;]].

11) You can't move a page to [[&lt;]].  It claims that "The requested page title
was invalid, empty, or an incorrectly linked inter-language or inter-wiki title."

12) I created [[User:Dbenbenn/&lt;]], then deleted it.  When I then edited the
page, the "View or restore 2 deleted edits?" message didn't have the usual link
to Special:Undelete.
Comment 1 David Benbennick 2005-08-23 22:28:31 UTC
13) If [[&lt;]] redirects to another page, the redirect message is "(Redirected
from <)" with no link.  The variable in [[MediaWiki:Redirectedfrom]] isn't
sanitized.
Comment 2 David Benbennick 2005-08-23 22:31:55 UTC
14) [[MediaWiki:Rclsub]] is another message where the parameter needs to be
sanitized, with & converted to &amp;
Comment 3 David Benbennick 2005-08-26 21:02:19 UTC
(In reply to comment #0)
> 10) A new variable is needed, like {{PAGENAME}} and {{PAGENAMEE}}, that 
gives anHTML-sanitized version of the page title. At the moment, there's 
no good way tofix [[MediaWiki:Newarticletext]], as it displays for 
[[&lt;]].

Perhaps {{PAGENAME}} should simply be updated.  After all, from the point 
of view of HTML, "&amp;lt;" actually ''is'' the title of the page whose 
plain-text title is &lt;.  There's no reason not to HTML-sanitize &, <, >, 
[, ], {, }, and | in the PAGENAME variable.

As an aside, ' can also cause trouble.  See

http://en.wikipedia.org/w/index.php?title=Image:%27%27I_can_smell_%27em%21%
27%27.jpg&action=edit

for a real-life example.  The '' is interpreted as "begin italics", and 
should be escaped to &apos; instead.
Comment 4 David Benbennick 2005-08-29 01:17:45 UTC
15) You can't move [[&lt;]] anywhere else.  The error message is "Fatal error:
Call to a member function on a non-object in
/usr/local/apache/common-local/php-1.5/includes/SpecialMovepage.php on line 198"
Comment 5 David Benbennick 2005-08-29 03:09:22 UTC
Created attachment 839 [details]
Patch to fix 3, 4, 5, 6, 7, and update Language.php slightly

Here's a short patch to fix points 3, 4, 5, 6, and 7.  (Incidentally, 8 and 14
got fixed independently.)

The patch also changes the defaults for [[MediaWiki:Addedwatchtext]],
[[MediaWiki:Removedwatchtext]], [[MediaWiki:Deletedtext]], and
[[MediaWiki:Undeletedtext]].  I add <nowiki> tags around the page title
parameter, so that the page title displays correctly in case it has '' in it.
Comment 6 David Benbennick 2005-08-29 03:56:27 UTC
Created attachment 840 [details]
also fix 2 and 13

The patch also fixes 2 and 13, and adds <nowiki> to the default for
[[MediaWiki:prefslogintext]] ([[User:''dbenbenn'']] is a valid user name!)
Comment 7 David Benbennick 2005-08-29 05:09:32 UTC
Created attachment 841 [details]
Fix 10 and 12.  1, 9, 11, and 15 remain

The patch now adds Sanitizer::wikiSanitize() to transform {{PAGENAME}}, fixing
point 10.  Note that now {{localurl:{{PAGENAME}}}} works for [[&lt;]], but
still not for [[*]].  (The wikiSanitize() function could probably be improved
by a PHP expert.)

The patch also modifies Skin.php to fix point 12.
Comment 8 David Benbennick 2005-08-29 19:00:28 UTC
Created attachment 842 [details]
better fix for point 10, {{PAGENAME}} sanitization

Here's a better implementation of Sanitizer:wikiSanitize().  It now makes the
display work right if {{PAGENAME}} appears at the beginning of a line in a page
called *, or '', or &, or ==foo==, or ;foo, or ----, or ~~~~
({{subst:PAGENAME}} in this last case).
Comment 9 David Benbennick 2005-08-29 20:05:50 UTC
Created attachment 843 [details]
better fix for point 10, also fix 11 and 15

wikiSanitize in the previous patch was broken, due to ;.  Fixed now.

Also, you can now move [[&lt;]].  Furthermore, to move a page to [[&lt;]], you
used to have to enter "&amp;lt;" in the "To new title" field---now "&lt;" works
as expected.
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-11 19:08:47 UTC
*** Bug 6986 has been marked as a duplicate of this bug. ***
Comment 11 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-08-13 21:13:28 UTC
This bug seems pretty broad.  Maybe someone should consider making it a tracker
and opening up separate bugs for the . . . separate bugs.
Comment 12 Thomas Bleher 2006-08-16 13:14:34 UTC
Category pages also suffer from this problem. Example:
http://de.wikipedia.org/wiki/Kategorie:Schriftzeichen (there's a lone & on the
page instead of &amp;)

Patch to fix it:
--- orig/includes/Linker.php
+++ mod/includes/Linker.php
@@ -316,8 +316,9 @@
                        $u .= '#' .
str_replace(array_keys($replacearray),array_values($replacearray),$anchor);
                }
                if ( $text == '' ) {
-                       $text = htmlspecialchars( $nt->getPrefixedText() );
+                       $text = $nt->getPrefixedText();
                }
+               $text = htmlspecialchars( $text );
                if ( $style == '' ) {
                        $style = $this->getInternalLinkAttributesObj( $nt, $text );
                }
@@ -385,8 +386,10 @@
                $u = $nt->escapeLocalURL( $query );

                if ( '' == $text ) {
-                       $text = htmlspecialchars( $nt->getPrefixedText() );
+                       $text = $nt->getPrefixedText();
                }
+               $text = htmlspecialchars( $text );
+
                $style = $this->getInternalLinkAttributesObj( $nt, $text, 'stub' );

                list( $inside, $trail ) = Linker::splitTrail( $trail );

Patch against mediawiki 1.7.1. Please apply.
Comment 13 Thomas Bleher 2008-02-08 21:35:27 UTC
At least the last issue doesn't seem to appear in the newest MediaWiki.
Someone should probably go through the other issues reported here and maybe open separate bugs for them...
Comment 14 Doodle77 2008-02-29 02:04:37 UTC
* is also not appropriately escaped, e.g.
http://en.wikipedia.org/wiki/*foo
Comment 15 Thomas Bleher 2008-02-29 11:43:28 UTC
(In reply to comment #14)
> * is also not appropriately escaped, e.g.
> http://en.wikipedia.org/wiki/*foo

* is not a metacharacter in HTML or CSS (please correct me if I'm wrong), so it doesn't need to be escaped.
Comment 16 Doodle77 2008-02-29 23:09:39 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > * is also not appropriately escaped, e.g.
> > http://en.wikipedia.org/wiki/*foo
> 
> * is not a metacharacter in HTML or CSS (please correct me if I'm wrong), so it
> doesn't need to be escaped.
> 

Yeah, I realized that a little after I posted that.
Should I post another bug for that?
Comment 17 Thomas Bleher 2008-03-04 10:25:24 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > * is also not appropriately escaped, e.g.
> > > http://en.wikipedia.org/wiki/*foo
> > 
> > * is not a metacharacter in HTML or CSS (please correct me if I'm wrong), so it
> > doesn't need to be escaped.
> 
> Yeah, I realized that a little after I posted that.
> Should I post another bug for that?

I'm not sure what you mean. The page validates correctly, so I don't see any bug there. Can you elaborate? 

Comment 18 Aaron Schulz 2008-03-24 21:01:28 UTC
These cases seemed to have been cleaned up as of now.

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


Navigation
Links