[IMPLEMENTED] SVGs with data-* attributes fail validation

Feature Requests Implemented Features
1

I have…

  • Read the following guideline: Troubleshooting and Support | Squidex. I understand that my support request might get deleted if I do not follow the guideline.
  • Used code blocks with ``` to format my code examples like JSON or logs properly.

I’m submitting a…

  • Regression (a behavior that stopped working in a new release)
  • Bug report
  • Performance issue
  • Documentation issue or request

Current behavior

I’m trying to upload an SVG to Squidex. Unfortunately, a lot of SVG files provided to us contain custom attributes which are not included in Squidex’s whitelist defined in libs/text/Squidex.Text/Svg/SvgAttributes.cs at main · Squidex/libs · GitHub

Apart from these attributes, the SVGs seem to be valid.

Has anyone seen this behaviour before? Maybe there’s a workround. :slight_smile:

Expected behavior

I’m uploading an SVG file to Squidex (asset field). The SVG image appears as a thumbnail preview and no validation errors are shown.

Minimal reproduction of the problem

I can’t upload SVG files to this issue. Here’s an example source code:

<svg id="Gruppe_264" data-name="Gruppe 264" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="107.502" height="77.98" viewBox="0 0 107.502 77.98">
  <g id="Gruppe_278" data-name="Gruppe 278">
    <g id="Gruppe_277" data-name="Gruppe 277" clip-path="url(#clip-path)">
      <path id="Pfad_198" data-name="Pfad 198" d="M77.438,48.562H35L19.422,61.017V48.562H9.484c-3.857,0-6.984-2.736-6.984-6.11V8.611C2.5,5.236,5.626,2.5,9.484,2.5H77.438c3.857,0,6.984,2.736,6.984,6.111V42.452C84.422,45.826,81.3,48.562,77.438,48.562Z" transform="translate(0.168 0)" fill="none" stroke="#0c669e" stroke-linejoin="round" stroke-width="5"/>
    </g>
  </g>
</svg>

Environment

App Name: test-empfehlen

  • Self hosted with docker
  • Self hosted with IIS
  • Self hosted with other version
  • Cloud version

Version: 7.13.0.0

Browser:

  • Chrome (desktop)
  • Chrome (Android)
  • Chrome (iOS)
  • Firefox
  • Safari (desktop)
  • Safari (iOS)
  • IE
  • Edge

Others:

Thanks alot for this wonderful product. :slight_smile:

2

Thanks as well for the nice words. I am not sure if this is a bug or not. The whitelisting has been added to prevent attacks with malicious SVGs. I have to investigate if it is save to allow data-attributes.

3

Thank you for looking into it. :slight_smile:

For what it’s worth, the svgo library (GitHub - svg/svgo: ⚙️ Node.js tool for optimizing SVG files) provides means to get rid of unknown attributes and similar things. The default setting is to keep data-attributes.

Unfortunately, data-attributes are not the only ones present in some of the files provided to us. There has been at least one occurrence of “enable-background” which seems to be deprecated but may be written by some (older versions of) Adobe products (see Gelöst: Re: Is it possible to save SVG without the enable-... - Adobe Community - 13506678)

4

Unfortunately I don’t remember the full argumentation. But the problem was security. I have read a view blog posts and recommendations and the general opinion was to have a whitelist instead of a blacklist.

I can probably allow data attributes and enable-background, but I cannot promise that it will be allowed forever, e.g. if I find a security risk, that I am not aware of right now.

In general I would just push your SVG to an optimizer before uploading it or you could also embed it in a text field directly to by pass the problem.

EDIT: What I read so far: data-* is not part of SVG, because SVG is not html. So technically it is correct not to allow it.

5

data-* is part of SVG and HTML.

See:

You are perhaps right to wonder if the intention to put data- tags on it is to run script things. If you are concerned a user might be able to inject code this way, there are perhaps some frameworks or libraries that could be on a web page that might pick up a data- tag and do something with it, for sure.

I actually had to clean up my SVG files when I uploaded them, too. There were one or more attributes it didn’t like about the ones I had.

Perhaps as developers we might be interested in editing the whitelist ourselves, seeing as how there could be many use cases. Or if it is a security concern, perhaps having different whitelists for different folders, or something like a policy per folder. Maybe we trust our ./assets/ but not our ./uploads/ for instance.

Possibly you seen one of many articles such as this regarding cross-site scripting (XSS) vulnerabilities.

A lesser-known vector for XSS attacks: SVG files - DEV Community