I can't see that there has been any recent discussion here on this subject. I have some users who have good reasons for wanting to upload .svg images, and I am considering implementing something to make it possible. This could be an extension, but it could also be a core enhancement, hence starting a discussion here.
I am not an expert on .svg format, but some quick searching has taught me that .svg files may contain scripts and are thus a potential security hole.
This discussion of a wordpress plugin for .svg seems to give a good overview of the subject.
With phpBB v3.2.2, I find that .svg attachments don't work which (from a security point of view) is a good thing, BUT if I externally host a .svg image, and link it in a post with [ img] [ /img] tags, it appears in the rendered phpBB post. I think that this is a bad thing, is it seems to allow a vector for malware via phpBB posts. So my first question is: Should the handling of [ img] tags should be tightened up to disallow externally hosted .svg images?
That question aside, the wordpress article linked above describes the use of a .svg sanitizer to remove potentially malicious elements form .svg files, making them reasonably safe to host. The sanitizer described there is Daryll Doyle’s SVG-Sanitizer library.
I would like feedback on the idea of implementing .svg attachcment handling in phpBB core, using Daryll Doyle’s SVG-Sanitizer library (which is GPLv2 licenced).
.svg as user uploaded attachments or [img] links
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
- DavidIQ
- Customisations Team Leader
- Posts: 1904
- Joined: Thu Mar 02, 2006 4:29 pm
- Location: Earth
- Contact:
Re: .svg as user uploaded attachments or [img] links
Rendering of the IMG tag contents is handled by the s9e Text Formatter. JoshyPHP will have to comment on what, if anything, is done to address this type of concern or if we would need to do something on our end.
JoshyPHP wrote:Poke
Re: .svg as user uploaded attachments or [img] links
they actually need to be allowed as we move forward as we are working to convert all images we use to allow SVG versions, ie icons, rank images, imagesets, etc. Since our main mechanic for sharing is through attachments on .com. We should implement something as you point out. SVG code is actually very standardized and we can also implement strict requirements to make checking upon upload relatively simple for our specific needs.
Re: .svg as user uploaded attachments or [img] links
It is not clear to me whether the "they" above refers to svg images that are part of phpBB core, or svg images which may be uploaded by admins or trusted users or svg images that may (in future) be uploaded by general users, or svg images which may (already) be externally hosted by any users using [ /img] tags.hanakin wrote: Thu Aug 16, 2018 7:29 pm they actually need to be allowed as we move forward as we are working to convert all images we use to allow SVG versions, ie icons, rank images, imagesets, etc. Since our main mechanic for sharing is through attachments on .com. We should implement something as you point out. SVG code is actually very standardized and we can also implement strict requirements to make checking upon upload relatively simple for our specific needs.
It is the apparent security hole in the [ /img] tags that I think needs to be recognised.
Re: .svg as user uploaded attachments or [img] links
SVG
We need to address what you are suggesting to allow for sharing of svg images via the forum or external links
We need to address what you are suggesting to allow for sharing of svg images via the forum or external links
Re: .svg as user uploaded attachments or [img] links
If disabling of external svg images in the s9e formatter turns out to be difficult, it is also possible to catch the links later at the point of the 'core.page_footer_after' event, which is where the camo image proxy extension modifies external image links with http:// addresses.
A bit ugly doing it there, but an easy place to add a simple and robust patch. I will produce a patch if asked.
A bit ugly doing it there, but an easy place to add a simple and robust patch. I will produce a patch if asked.
Re: .svg as user uploaded attachments or [img] links
Scripts are not executed by the browser if the resource is fetched as an image. In order to execute scripts you need to link to the SVG image and for the target to visit the link. If the upload of SVG images is disabled OR if they are served with a text/plain MIME type OR possibly if they are systematically served with a Content-Disposition header.v12mike wrote: Wed Aug 15, 2018 6:31 pm I am not an expert on .svg format, but some quick searching has taught me that .svg files may contain scripts and are thus a potential security hole.
As a user, whenever I want to attach a file that isn't allowed I just put it inside a ZIP.
FYI I didn't receive a notification. It's not in my spam folder either.
Nothing. You could add a filter that rejects URLs that ends in .svg but otherwise there's no knowing what MIME type a given URL will be associated with so it's not really useful.DavidIQ wrote: Thu Aug 16, 2018 2:01 pm what, if anything, is done to address this type of concern or if we would need to do something on our end.
Re: .svg as user uploaded attachments or [img] links
Thanks for the information and links. I will do some more reading.
If SVGs served as images are not a security threat, am I correct in thinking that the non-support of the image/svg+xml mime type by phpBB (for display as an in-line image) is only becausse no-one has got around to implementing it yet?
If SVGs served as images are not a security threat, am I correct in thinking that the non-support of the image/svg+xml mime type by phpBB (for display as an in-line image) is only becausse no-one has got around to implementing it yet?
Re: .svg as user uploaded attachments or [img] links
If you let someone upload a SVG, it becomes possible for someone to link to it and then it becomes possible to execute scripts. Same as letting users upload a HTML file.
-
- Registered User
- Posts: 15
- Joined: Fri Sep 11, 2015 12:55 pm
Re: .svg as user uploaded attachments or [img] links
Embedded SVGs actually pose a minor security threat in phpBB, since you can add an SVG bomb to a post and crash or seriously slow down the user's browser and computer by using all the available memory.
Maybe browsers have improved their way of handling this since it happened on my forum but back then some users had no choice but to restart their computers.
On a side note, while a very useful feature, allowing remote resources to be loaded inside posts (or better, signatures) lets potential attackers collect the IP addresses of all visitors, and I've had malicious users cross-reference that with live data from the Who's Online? page (using a basic scraper and parser) to automatically obtain the IP addresses of almost all registered users. It's probably good to keep that in mind.
Maybe browsers have improved their way of handling this since it happened on my forum but back then some users had no choice but to restart their computers.
On a side note, while a very useful feature, allowing remote resources to be loaded inside posts (or better, signatures) lets potential attackers collect the IP addresses of all visitors, and I've had malicious users cross-reference that with live data from the Who's Online? page (using a basic scraper and parser) to automatically obtain the IP addresses of almost all registered users. It's probably good to keep that in mind.