Thanks MZMcBride, it looks like Chrome and Opera treat a %2E in the hostname of the url as a valid . character.

The quick fix is just to replace %2e characters before matching, like the fix for bug 12896. But it may be good to do more extensive normalization in the near future. Maybe something like:

function normalizeUrl( $url ) {
$bits = wfParseUrl( strtolower( Sanitizer::cleanUrl( $url ) ) );
$bits['host'] = str_replace( array( '%2e', '．'), '.', $bits['host'] );
$bits['path'] = str_replace( array( '%2e', '．'), '.', $bits['path'] );
return wfAssembleUrl( $bits );
}

Created attachment 11941
Decode %2E before matching blacklist

Attached:

(In reply to comment #1)

The quick fix is just to replace %2e characters before matching, like the fix
for bug 12896. But it may be good to do more extensive normalization in the
near future.

Hmmm, this is something to do with file inclusion syntax's link parameter specifically, I think.

If I attempt to insert "http://badsite%2Ecom" or "[http://badsite%2Ecom hello]" or "[[File:Symbol wtf vote.svg|10px|link=http://badsite.com]]" into a wiki page, it appropriately fails if the domain is blacklisted.

However, "[[File:Symbol wtf vote.svg|10px|link=http://badsite%2Ecom]]" works.

URL unquoting (i.e., changing "%2E" to ".", etc.) is already being done in some cases for comparison against the spam blacklist, so the question is why this particular syntax is able to be saved without being flagged as blacklisted.

Nice catch. Before most links are added to the list of external links, they're passed through Parser::replaceUnusualEscapes first. Image links are not at the moment.

Created attachment 11942
Filter urls with replaceUnusualEscapes before adding to external links list

This would be instead of patching SpamBlacklist, so that any other uses of the external links list will have consistent url normalization.

Attached:

I think it'd be better to move the normalization check directly into ParserOutput::addExternalLink. You should never not normalize the link, and doing it separately seems to be inviting people to forget.

To that end:

Also, a similar issue is present in <gallery> tags, which the above patch fixes.

Closing for ease of tracking progress. Patches attached to parent bug, due for next release

Change 346846 merged by jenkins-bot:
[mediawiki/core@master] SECURITY: Always normalize link url before adding to ParserOutput

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

Change 346865 merged by jenkins-bot:
[mediawiki/core@REL1_28] SECURITY: Always normalize link url before adding to ParserOutput

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

Change 346855 merged by jenkins-bot:
[mediawiki/core@REL1_27] SECURITY: Always normalize link url before adding to ParserOutput

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