in my texteditor:
(image: 01.jpg alt: Das Café)
in the browser:
<figure><img alt="Das Café" src="/media/pages/vereinscafe/2dd73d1bae-1762184621/01.jpg"></figure>
How can this conversion into entities be prevented?
Thanks : )
Why do you want to prevent it? Or what is the problem you are facing?
Hi Sonja.
Unnecessary entities make the source code difficult to read, for example when debugging.
There is no need to escape a Unicode character “é” as an entity.
Kirby doesn’t do that with other content either.
So it’s also about consistency.
Andreas
Non-ASCII characters are HTML entity encoded in Kirby in the context of HTML attributes for security reasons.
We can probably discuss, which characters exactly should or shouldn’t be encoded, but then, the source code is not for reading your documents.
But to answer your question: If you want to get rid of the encoding, you need to overwrite the image kirbytag (or other kirbytags that might do this) with your custom version that doesn’t use Html::img().
Could you explain the security reasons? If you find the time for that. I’m curious.
I find it hard to imagine that umlaut entities increase security compared to Unicode characters.
Perhaps you were thinking of characters that play a role in HTML syntax, such as “<” and “>”. That makes sense immediately.
Back to my motive:
Of course, I read the content in the editor or text file. But compared to other CMSs, Kirby produces excellent, “clean” and tidy code. From this perspective, it seems natural to me to avoid unnecessary encoding in entities.
It’s just a suggestion : ) It just struck me.
Regarding your suggestion to overwrite the kirbytag image: I don’t have the skills to do that.
Sure. HTML entities effectively prevent a majority of XSS attacks. This is because by using and only allowing HTML entities it is ensured that it can only be interpreted as such and not be executed by the browser engine. So it’s a purely technical solution to disallow XSS attacks — and for reference — not a complete one, it does prevent the most common XSS, not all.
To make it a bit more complex now, it’s certainly possible to use unicode encoding to obfuscate my attack. This relies on the human (and/or simple tech) part that it’s hard to read encoded strings and/or impossible (invisible characters). In this case, Kirby would not output the invisible unicode character but instead show the encoded string for it.
The easiest solution for a XSS is to set “/><script>eval(doSomethingHere()) into a field value. If you don’t check by stripping such characters (often not wanted, therefore Kirby does not do) or encoding it, this becomes a security problem very quickly.
This may be a good idea though but it’s quite complex. You will need to build a set of “allowed characters” and care/update it manually. In an open source project, this is a source file you need to really be careful about when accepting Pull/Merge Requests because of its security impact.
But having such an allowed list in place would make things a bit easier for machine readability, for example if you want to parse the string in your app or another API.
Thanks for your comments, Anselm.
I don’t quite understand everything yet.
Are you talking about
-
the existence of “Named Entities instead of Unicode Characters (UTF8)” in the delivered source code, or
-
the existence in processes on the server before delivery?
XSS are done in a browser, not on the server so I’m talking about the result by the server same as any user will get the page.
The characters that need escaping in an HTML attribute value are ", ', <, and >. (One can also escape & to ensure well-formed XML or to prevent the content authors from writing HTML entities, but that’s not strictly necessary for security.)
Escaping more characters is wasteful: the HTML output will take more bytes over the wire than necessary. But it’s probably negligible for use cases like the (image) tag. It can be more of an issue for application pages where a lot of metadata is stored in HTML attributes (for framework hydration, complex forms or other dynamic features).
It looks like the code involved here may use htmlentities() instead of the less aggressive htmlspecialchars().