Fixed SVG favicons not supported in unfurled URLs

[DeltaHF]

Affected version

2.2.8

If a URL is unfurled and the target page references an SVG favicon, the favicon is not displayed in the unfurled preview.

As an example, here is an unfurled link to a CSS-Tricks article which references the following favicons:

<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="icon" href="https://i1.wp.com/css-tricks.com/wp-content/uploads/2021/07/star.png?fit=32%2C32&#038;ssl=1" sizes="32x32" />
<link rel="icon" href="https://i1.wp.com/css-tricks.com/wp-content/uploads/2021/07/star.png?fit=180%2C180&#038;ssl=1" sizes="192x192" />

Despite defining multiple favicon formats, none are displayed in the unfurled preview:

We Analyzed 425,909 Favicons | CSS-Tricks

This is a neat idea for a research project. The big map is fun, but the research had some tidbits in it worth looking at.

css-tricks.com

Closer inspection of the page source reveals the icon failed to load because the image proxy attempted to load the entire page itself, triggering the onerror behavior:

<span class="js-unfurl-favicon">
    <img src="/community/proxy.php?image=https%3A%2F%2Fcss-tricks.com%2Fwe-analyzed-425909-favicons%2F&amp;hash=459ab8051b2237b520a9f851f20545eb&amp;return_error=1" alt="css-tricks.com" class="bbCodeBlockUnfurl-icon" data-onerror="hide-parent"/>                       
</span>

Of course, if the image URL is on the site's own domain, the image proxy is bypassed. This means that sites using XenForo and SVG favicons will always show a broken image placeholder instead of the favicon for unfurled links to their own domain.

For example, I use a custom SVG favicon with a media query to support both light and dark modes:

<link rel="icon" href="/favicon.svg">

This causes links to other posts in my site's own forum show a broken image favicon:




(View this post here.)

The src for that image is the full page URL, as you can see here:

<span class="js-unfurl-favicon">
    <img src="https://www.gtplanet.net/forum/threads/gtplanet-update-log-new-features-and-site-changes.296680/post-13538309/" alt="www.gtplanet.net" class="bbCodeBlockUnfurl-icon" data-onerror="hide-parent" />
</span>

 

[digitalpoint]

I think the root of it is that XF's image proxy doesn't support SVG images (it supports GIF, JPG, PNG, ICO and WEBP). I assume it's intentional that SVG isn't supported by the image proxy because an SVG image can have embedded JavaScript that executes inside the image itself. You could get some really malicious stuff happening by allowing users to execute JavaScript they wrote and then stuck in an image. That image then is run on the host domain (since the proxy image is coming from the XF site). You know... doing things like inserting ads to the site, stealing login credentials of anyone that viewed the image, etc.

The only way to realistically do it would go down a road of trying to whitelist certain allowed SVG tags/attributes inside the image itself and hope you didn't forget something. Would be like trying to universally sanitize a webpage and remove all the different ways JavaScript could be on that page.

 

[DeltaHF]

I think the root of it is that XF's image proxy doesn't support SVG images (it supports GIF, JPG, PNG, ICO and WEBP). I assume it's intentional that SVG isn't supported by the image proxy because an SVG image can have embedded JavaScript that executes inside the image itself. You could get some really malicious stuff happening by allowing users to execute JavaScript they wrote and then stuck in an image. That image then is run on the host domain (since the proxy image is coming from the XF site). You know... doing things like inserting ads to the site, stealing login credentials of anyone that viewed the image, etc.

The only way to realistically do it would go down a road of trying to whitelist certain allowed SVG tags/attributes inside the image itself and hope you didn't forget something. Would be like trying to universally sanitize a webpage and remove all the different ways JavaScript could be on that page.

Embedded scripts are not executed in SVG files if they are displayed via an <img> tag, but yeah, the files could still be accessed directly and code could be executed so it's understandable why they aren't displayed by the proxy.

Anyway, that's actually still the point: if XenForo detects an SVG favicon, it should keep parsing the page to see if it can find another rel='icon' defined in another format that it can use.

At present, if an SVG favicon exists at all (or maybe if it's the first one parsed on the page?), it won't be displayed in the unfurled preview. And worse, if it's on the same site, the onerror function does not run and it is not hidden, showing a broken image placeholder instead.

 

[XF Bug Bot]

Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.9).

Change log:

Attempt to determine first proxyable favicon when fetching page metadata

There may be a delay before changes are rolled out to the XenForo Community.

 

[pcguy]

Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.9).

Change log:

There may be a delay before changes are rolled out to the XenForo Community.

I have xenforo 2.1 is there a way to fix this there?