Make non-existent messages be html safe regardless of output format
authorBrian Wolff <bawolff+wn@gmail.com>
Wed, 29 Jun 2016 22:09:18 +0000 (18:09 -0400)
committerBrian Wolff <bawolff+wn@gmail.com>
Wed, 29 Jun 2016 22:59:30 +0000 (18:59 -0400)
commit184658eb32f6c5561cd3789716bd98c1e9f0ba04
tree15515291b04bfe3eb6845735031383db823960c3
parent62638d784524b5e9a8faa600ac3c961481769f85
Make non-existent messages be html safe regardless of output format

If you have a non-existent message in the output, chances are its
user-controlled. If the message has the ->plain() or ->text()
format, the output used to be not safe for html. Obviously people
should not be using those format types where html is being outputted,
but sometimes that happens. I think we should prioritize always being
safe over the fallback content not potentially being double escaped.

Additionally switch the enclosing brackets to be fancy unicode
characters, to sidestep the escaping issue on the enclosing brackets.

So previously, wfMessage( 'script>alert(1)</script' )->text() would
have outputted <script>alert(1)</script>. Now it outputs
⧼script&gt;alert(1)&lt;/script⧽. No sane message key will include
< or >, so this would really only come up if the user can control
the message key name.

This goes somewhat against T68199.

Change-Id: Ic8a60892b8e847e6021494c10968814aac391731
includes/Message.php
tests/parser/parserTests.txt
tests/phpunit/includes/MessageTest.php
tests/phpunit/includes/StatusTest.php