Bug 202308091 Webpages module removes necessary html elements for custom pages

Wed, 09 Aug 2023 11:55:34 +0200

adminsforum@hubzilla.org

hubzillar wrote the following post Wed, 09 Aug 2023 11:55:34 +0200

Bug 202308091 Webpages module removes necessary html elements for custom pages

Using the instructions of https://completehostingguide.com/article/creating-a-custom-page-on-a-channel-in-hubzilla?f=&owt=047a080a5cf79685f4171e4c62833777

it is observed that the following html elements are removed by hubzilla code for the module 'webpages'

<!doctype html>
<html lang="en">
    <head>
        <meta charset="UTF-8">
        <link rel="stylesheet" href="/path/to/file.css" />
        <link rel='preconnect' href='/path/to/file' />
        <title></title>
    </head>
    <body>
</body>
</html>

The following is added to the web page:

<script>var homebase = hubzilla.domain/channel/...;
</script>

#hubzillabug #hubzillabug202308 #hubzillabug202308091

show all 10 comments

Sun, 13 Aug 2023 23:32:30 +0200

M. Dent

dm42@my.hosted.social

@hubzillar

Here is the description of HTMLPurifier from their page:

HTML Purifier is a standards-compliant HTML filter library written in PHP. HTML Purifier will not only remove all malicious code (better known as XSS) with a thoroughly audited, secure yet permissive whitelist, it will also make sure your documents are standards compliant, something only achievable with a comprehensive knowledge of W3C's specifications.

HTML Purifier is only ever going to allow a subset of "safe" raw html through.

I imagine, but don't know for sure, that the blocked elements prevent the hapless naive user from accidentally stomping on core template elements.  From what I can see in the specs, they are simply special-purpose DIVs.  If that's the case, their behavior should be replicable by other means.

Creating a 100% pure/raw HTML web page with unlimited leeway in included elements (including JS and others), is far beyond what the software is designed to do  -- and securing an environment that allows such would be virtually impossible.  The potential for data exfiltration and nefarious activities by users of the system is just too great.  Anyone desiring to set up a hub with such capabilities, if they are capable of writing the HTML, are very likely also capable of writing an addon/plugin to accomplish what they desire.

To expect such behavior in a system that permits that kind of user-generated content is a liability to the project overall.  If you need that granular level of control, you probably don't want to be using this sort of system to develop your pages in the first place.

If your concern really is a matter of insufficient documentation - once you've figured out the parameters and limitations, it would be a great help to the project if you update the docs and submit a PULL request!

It would be most gratefully received!

Mon, 14 Aug 2023 04:58:29 +0200

Scott M. Stolz

scott@biztechtonics.net

I am wondering if there is some kind of regression, because I don't remember it stripping out <html> <head> and <body> tags when using the none template while >_ enabled code is enabled.

It's been awhile since I checked. Has this changed, or have I never noticed it?

Mon, 14 Aug 2023 13:52:13 +0200

𝓒𝓱𝓻𝓲𝓼

chris@im.allmendenetz.de

the code

<!doctype html>
<html lang="en">
    <head>
        <meta charset="UTF-8">
        <link rel="stylesheet" href="/path/to/file.css" />
        <link rel='preconnect' href='/path/to/file' />
        <title></title>
    </head>
    <body>
</body>
</html>

can be saved on my hub with out any conflicts

so it may depend of what kind of file the line

<link rel='preconnect' href='/path/to/file' />

tries to pull