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

WordPress Trac noreply at wordpress.org
Tue Jun 2 22:18:27 UTC 2015


#24251: Reconsider SVG inclusion to get_allowed_mime_types
--------------------------------------+------------------------------
 Reporter:  JustinSainton             |       Owner:
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Upload                    |     Version:
 Severity:  minor                     |  Resolution:
 Keywords:  dev-feedback needs-patch  |     Focuses:
--------------------------------------+------------------------------

Comment (by LewisCowles):

 Hello @jimmy.smutek & @iandunn,

 For clarity @jimmy.smutek I have a plugin written that accomplishes adding
 SVG including allowing upload and selection via customiser, it was the
 first thing I did with a view to SVG support. If you google CSS-Tricks SVG
 you will find the post quickly with a link to the gist.

 Unlike my other plugins, I do not feel it is right that SVG is considered
 a site-specific / ecosystem-specific use-case. In 2015 it is an absolute
 horror that something, as widely used as WP, uses such old and limited
 file-format support.

 For clarity with @iandunn, you clearly do not understand the supposed
 security risk being talked about fully. This is not a file-system bug or
 privilege escalation, or SQL hack. It affects more than just SVG as a
 domain, and as I understand it from the W3C, could affect many taggable
 file formats accepting script tags, or javascript, and data uri's, css
 files linking SVG from external resources could be a bigger risk (so HTML,
 xhtml, CSS and ironically JS, are also potential candidates for such
 hacks, and they are not banned).

 In short what this is, represents a series of ill-informed people,
 supposing obscure security risks, which can be mitigated with even the
 most half-witted security policies, whilst WP allows users to use charsets
 with much more realistic potential risk to a WP install.

 Also because these are front-end hacks being spoken about, unless you are
 on a page with the linked SVG, allow users that are untrustworthy to use
 your WP, upload files etc, your visitors would not be at risk; it would be
 simple to mitigate, and it would not affect the backend, without
 significant intervention from an admin-level user.

 There is another plugin, I am told will be updated using some of my code
 that also handles the SVG sanitization process for paranoid users. If you
 have CPU cycles to waste and untrustworthy users, feel free to use it.
 Personally, I think detection as part of a compliance framework, and
 autiting + remittance is a better fix for potential security issues.

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


More information about the wp-trac mailing list