Page MenuHomePhabricator

The output of wfMessage( 'i-dont-exist' )->text() should not have its entities html encoded
Closed, DeclinedPublic

Description

wfMessage( 'i<dont>exist' ) has a two possible outputs depending on the format utilized to output the content, either:

plain: <i&lt;dont&gt;exist>
text/escaped/parse: &lt;i&lt;dont&gt;exist&gt;

Note that i'm not encouraging special characters in i18n keys, merely showing what the current implementation does.

The method documentation for Message::text() states that it is unescaped message text. Documentation for Message::plain() states that it is unescaped untransformed text. Based on the documentation my inference is that text() and plain() should have the same output, with {{FOO}} messages transformed only in the text method.

One option for escaping is to escape as close to the output as possible. In an API response consumed by client-side javascript the strings within the JSON should be plain text. This plain text is then escaped for output in the templating layer of the client side javascript. Using this setup mistyping an i18n key looks like you have not only bad i18n key but also a double-encoding issue. Upon further investigation the double-encoding only happens with the non-existent key.

I'm proposing the output should be:

plain/text: <i<dont>exist>
escaped/parse: &lt;i&lt;dont&gt;exist&gt;


Version: unspecified
Severity: normal

Details

Reference
bz66199

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:17 AM
bzimport set Reference to bz66199.
bzimport added a subscriber: Unknown Object (MLST).

Change 137458 had a related patch set uploaded by EBernhardson:
Correct output of wfMessage( 'non-existent-msg' )->text()

https://gerrit.wikimedia.org/r/137458

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

Change 137458 merged by jenkins-bot:
Message: Correct output of wfMessage( 'non-existent-msg' )->text()

https://gerrit.wikimedia.org/r/137458

I'm not really a fan of this. If message is missing, key is probably user controlled. Occasionally people use the wrong escaping type for messages. Being able to get an XSS if you can edit a MediaWiki namespace page is a lot better than just if you can somehow convince the message name to be "script>foo();</script".

I have an alternate proposal at https://gerrit.wikimedia.org/r/#/c/296665/

Nemo_bis changed the task status from Resolved to Declined.Jul 2 2016, 6:07 PM
Nemo_bis assigned this task to Bawolff.
Nemo_bis subscribed.

Patch was merged; properly closing this.