Spam blacklist entries:
\bwikipediaforum\.com\b
\bwikipediocracy\.com\b
File inclusion syntax that makes a working disallowed link:
[[File:Symbol wtf vote.svg|20px|link=http://wikipediocracy%2Ecom]]
Version: unspecified
Severity: normal
• MZMcBride | |
Mar 15 2013, 3:50 AM |
F7104295: T48143-REL1_27.patch | |
Mar 30 2017, 11:57 PM |
F7104297: T48143-REL1_28.patch | |
Mar 30 2017, 11:57 PM |
F7104296: T48143-REL1_23.patch | |
Mar 30 2017, 11:57 PM |
F7104294: T48143-master.patch | |
Mar 30 2017, 11:57 PM |
F7103902: T48143-REL1_28.patch | |
Mar 30 2017, 11:35 PM |
F7103900: T48143-master.patch | |
Mar 30 2017, 11:35 PM |
F7103901: T48143-REL1_27.patch | |
Mar 30 2017, 11:35 PM |
F7102995: T48143-master.patch | |
Mar 30 2017, 11:00 PM |
Spam blacklist entries:
\bwikipediaforum\.com\b
File inclusion syntax that makes a working disallowed link:
Version: unspecified
Severity: normal
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | • demon | T161996 Release MediaWiki 1.28.1/1.27.2/1.23.16 | |||
Resolved | Reedy | T140591 MediaWiki 1.28.1/1.27.2/1.23.16 security release | |||
Resolved | Bawolff | T48143 Spam blacklist ineffective on encoded URLs inside file inclusion syntax's link parameter |
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 );
}
(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
Change 346865 merged by jenkins-bot:
[mediawiki/core@REL1_28] SECURITY: Always normalize link url before adding to ParserOutput
Change 346855 merged by jenkins-bot:
[mediawiki/core@REL1_27] SECURITY: Always normalize link url before adding to ParserOutput