Last modified: 2013-07-16 23:00:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T53367, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 51367 - Extension checking is only done client-side
Extension checking is only done client-side
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
1.19.7
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-15 14:53 UTC by Mark A. Hershberger
Modified: 2013-07-16 23:00 UTC (History)
6 users (show)

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


Attachments

Description Mark A. Hershberger 2013-07-15 14:53:25 UTC
Reported on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716957

 Default allowed extensions for file upload are only:
 $wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg' );

 Under Firefox & Chrome it's indeed impossible to upload a pdf file under
 those settings.
 But under IE it's possible without warning or error. 

 A quick inspection seems to indicate that the file extension is only
 checked on the client side via javascript and IE does not do a proper job.
 Note that "application/pdf" is by default in the $wgTrustedMediaFormats
 array.

 IMHO file extension checks must also be enforced on server side, and, if
 possible, a js workaround should be provided for proper handling in IE.
 Malicious pdfs do exist...

I did some cursory checking of the 1.19 codebase and it does seem like this is not checked server-side.
Comment 1 Mark A. Hershberger 2013-07-15 18:42:25 UTC
Just tested a debian installation with uploads enabled and javascript off and got ".pdf" is not a permitted file type. Permitted file types are png, gif, jpg, jpeg.

But maybe IE is sending the file name in a way that confuses mediawiki?
Comment 2 Mark A. Hershberger 2013-07-15 18:46:53 UTC
Even renaming my sample pdf to .jpg and re-uploading shows it failing.  WORKSFORME?
Comment 3 Chris Steipp 2013-07-15 19:06:30 UTC
I haven't been able to duplicate or confirm the issue, but it would be a very serious issue if that is happening.

The debian reporter is going to send me his LocalSettings tomorrow. In the meantime, if anyone is able to reproduce this, please report details.

In general:
* Checking to ensure the file extension is allowed is done in UploadBase::getTitle() if $wgCheckFileExtensions and $wgStrictFileExtensions are true.
* Checking is also done in javascript (./skins/common/upload.js)
* If the javascript check is bypassed (either with noscript, or making a modification with a javascript debugger), the server side checks seem to still run (in all cases that I've been able to test)
Comment 4 Chris Steipp 2013-07-16 17:38:21 UTC
The reporter actually had $wgCheckFileExtensions = false.

This seems to be the desired behavior for MediaWiki based on https://bugzilla.wikimedia.org/show_bug.cgi?id=14220
Comment 5 Chris Steipp 2013-07-16 23:00:49 UTC
Making public in case anyone else hits this

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


Navigation
Links