[wp-trac] [WordPress Trac] #24251: Reconsider SVG inclusion to get_allowed_mime_types

WordPress Trac noreply at wordpress.org
Tue Jul 7 00:25:47 UTC 2015


#24251: Reconsider SVG inclusion to get_allowed_mime_types
---------------------------+-----------------------
 Reporter:  JustinSainton  |       Owner:
     Type:  enhancement    |      Status:  reopened
 Priority:  normal         |   Milestone:
Component:  Upload         |     Version:
 Severity:  normal         |  Resolution:
 Keywords:  early          |     Focuses:
---------------------------+-----------------------

Comment (by enshrined):

 > Note the library in comment:20 is for proof of concept. As it's 5.3+,
 its not usable in core. Further, it's not a mature (in terms of
 development) or complete sanitizer.

 I agree, this isn't at all mature as it's only been around a few weeks.
 It's also only aimed at sanitizing SVGs as I didn't see much reason to
 implement any more when tools like htmlpurifier are already established in
 that area.

 > If WordPress were to ever allow SVGs, the sanitize library would not
 only need to work well, it would also need to be thoroughly tested, in
 large scale production environments. Literally by design, SVGs are
 designed to be insecure. Just as we continue to find new MySQL
 vulnerabilities (not with WordPress specifically but with MySQL in
 general), SVGs continue to have entirely new vectors found.
 >
 > The second something like SVGs were to get into WordPress core, our
 library would be scrutinized, poked and prodded for security holes.

 I agree, I'd hate to see something rushed into core, only to open up major
 security holes and you're right, a library such as this one would have to
 be continually maintained and updated to keep it secure.

 My thinking around it is that a lot of developers seem to allow SVGs into
 WordPress anyway, eased by articles like https://css-
 tricks.com/snippets/wordpress/allow-svg-through-wordpress-media-uploader/
 which show how to allow them, without even a mention of the security
 risks. I'm guessing that a lot of developers that allow SVG uploads aren't
 aware of the risks of SVGs and therefore some sanitization is better than
 none, even if you still have to manually allow SVGs as you do now.

 > Also there would be a significant presence to using a library that
 another large scale company uses in production, thus guaranteeing it's
 current development but also removing core team from having to maintain
 yet another library, like for example the Dropbox zxcvbn library.

 I'm not aware of any established SVG sanitization libraries out there but
 please do let me know if you've seen one. Wikimedia have a version baked
 into their uploads handler (below) which I'll pull apart at some point but
 from the looks of it, it's very regex based. I'll try and get in contact
 with someone R.E. that though to see why they did it that way

 https://git.wikimedia.org/raw/mediawiki%2Fcore.git/eba9321b2b75823f8e9797398f44944e8a05389a/includes%2Fupload%2FUploadBase.php

--
Ticket URL: <https://core.trac.wordpress.org/ticket/24251#comment:42>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list