w3.org/2000/svg

colak · 2022-10-29 16:14:15

As you may have read in a previous thread, Julian and I have been experimenting with CSP.

I thought that it would be possible to fully protect the txp directory by just using: Header set Content-Security-Policy: "default-src 'self' data: 'unsafe-inline' 'unsafe-eval'; font-src 'self'; manifest-src 'self'; img-src 'self'; frame-src 'self';" but the way the sprites are used in textpattern CSS forces us to make an exception for the img-src: Header set Content-Security-Policy: "default-src 'self' data: 'unsafe-inline' 'unsafe-eval'; font-src 'self'; manifest-src 'self'; img-src 'self' data: 'unsafe-inline' 'unsafe-eval' http://www.w3.org/2000/svg; frame-src 'self';".

The same result can be by using the following in the html:

<svg xmlns="http://www.w3.org/2000/svg" width="0" height="0">
    <symbol viewBox="xxx" id="id_name">
        <path fill="none" d="xxx" />
        <path d="xxx" />
    </symbol>
etc.

whicch interestingly abides with the img-src 'self'; and does not block the images.

Would it be a prudent idea to move these svgs in the html and save us this exception?

Bloke · 2022-10-29 16:59:16

Phil might have something to say about this but on first glance I can’t see a downside to including the SVG inline in the HTML like that.

phiw13 · 2022-10-30 02:44:51

You are talking about the admin side, right ?
1/ on including the SVG image src – one objection: it is part of the theme. If you’d like to insert it in page, it should be inserted in either the header or the footer part of the theme file (in case of theme Hive: in the hive.php file) other themes can use other (SVG) images as they see fit.

2/ I don’t understand what exactly you are trying in your img-src directive. Here is what I currently use for the /textpattern folder: img-src 'self' data: and no images are blocked – jpeg, png, webp and SVG, including data-uri.

Here is the whole CSP block for the admin side:

Header set Content-Security-Policy "default-src:self; base-uri 'self'; block-all-mixed-content; form-action 'self'; img-src 'self' data: ; media-src 'self'; object-src 'none'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'"

As mentioned in the other thread, the public side has a stricter CSP header.

3/ FWIW, the http://www.w3.org/2000/svg in a SVG image is not a source of anything but a reference (to the namespace for SVG, that defines all elements – SVG being XML). The browsers have build-in knowledge of it.

4/ I don’t think you need to use all that unsafe-eval, especially not in the default-src directive. That is a bit like leaving you front-door open and advertising that fact on Twitter.

PS – edit: here is quick refresher on namespaces

Last edited by phiw13 (2022-10-30 03:06:19)

colak · 2022-10-30 05:28:01

This is what is loaded with the w3 exception, and this is when I use img-src 'self'

2/ I don’t understand what exactly you are trying in your img-src directive. Here is what I currently use for the /textpattern folder: img-src 'self' data: and no images are blocked – jpeg, png, webp and SVG, including data-uri.

The addition of the empty data: indeed solved it.

colak · 2022-10-30 07:21:04

phiw13 wrote #334044:

Here is the whole CSP block for the admin side:

Header set Content-Security-Policy "default-src:self; base-uri 'self'; block-all-mixed-content; form-action 'self'; img-src 'self' data: ; media-src 'self'; object-src 'none'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'"...

That works after changing default-src:self; to default-src 'self';. Thanks so much!!!

phiw13 · 2022-10-30 07:31:42

colak wrote #334049:

That works after changing default-src:self; to default-src 'self';. Thanks so much!!!

Ooops -:( how did that get there ? My locally saved snippets are sometimes in a bit of a messy state…

Glad I could help some.

philwareham · 2022-11-01 09:19:50

Textpattern 4.9 already has options to set CSP, see here.

Admittedly, I haven’t checked the latest Content Security Policy advances over the last year so there may be changes needed (the policy was constantly in flux when I added that feature).

Is that what you are looking for?

For Textpattern 4.8 you could probably take those rules and manually add them to your .htaccess or server config.

colak · 2022-11-01 12:36:57

philwareham wrote #334064:

Textpattern 4.9 already has options to set CSP, see here.

Admittedly, I haven’t checked the latest Content Security Policy advances over the last year so there may be changes needed (the policy was constantly in flux when I added that feature).

Is that what you are looking for?

For Textpattern 4.8 you could probably take those rules and manually add them to your .htaccess or server config.

Do those rules better work in the config or the htaccess?

Also, I found that for some cases (directed to clients), the rules block content, such as 3rd party iframes, because of how the preview urls are constructed using the textpattern directory. ie /textpattern/?txpreview=2.1636763305 and not those of the section the articles belong to. ie /my_section/?txpreview=2.1636763305.

phiw13 · 2022-11-01 12:52:57

colak wrote #334067:

Do those rules better work in the config or the htaccess?

As discussed in the other thread, those rules won’t work inside the config.php file for 4.8.8 (the whole mechanism is not implemented yet in 4.8.8).

Also, I found that for some cases (directed to clients), the rules block content, such as 3rd party iframes, because of how the preview urls are constructed using the textpattern directory. ie /textpattern/?txpreview=2.1636763305 and not those of the section the articles belong to. ie /my_section/?txpreview=2.1636763305.

That is certainly a possibility. You’ll probably need to tweak the iframe directive – something like frame-src 'self' this-other-domain.tld; (untested).

colak · 2022-11-02 05:25:50

phiw13 wrote #334069:

As discussed in the other thread, those rules won’t work inside the config.php file for 4.8.8 (the whole mechanism is not implemented yet in 4.8.8).

Indeed, I know. My question was whether it will be better to include those rules in the htaccess file rather than the config.

That is certainly a possibility. You’ll probably need to tweak the iframe directive – something like frame-src 'self' this-other-domain.tld; (untested).

This is what I do now. The suggestion was to preview articles using the ‘front-end’ url structures in order to create a more strict/and more secure CSP for the textpattern directory.

phiw13 · 2022-11-02 07:49:10

colak wrote #334077:

Indeed, I know. My question was whether it will be better to include those rules in the htaccess file rather than the config.

hmm. Setting it up via the config.php has one advantage, I think: easier working with nonces, as Textpattern would do all the work. Mixing those (randomly generated) nonces into the htaccess file sounds more …complicated. on the flip side, having the CSP directives set in the htaccess means those apply to files outside of the TextpatternHTML, like a stylesheet. I don’t how much browsers take these CSP directives into account when loading e.g a stylesheet. But you might have additional .html files on the server, created outside TXP that might benefit.

This is what I do now. The suggestion was to preview articles using the ‘front-end’ url structures in order to create a more strict/and more secure CSP for the textpattern directory.

Ah, OK. I misunderstood you there. I would certainly do the same in that case.

Textpattern CMS

Textpattern CMS support forum

#1 2022-10-29 16:14:15

w3.org/2000/svg

#2 2022-10-29 16:59:16

Re: w3.org/2000/svg

#3 2022-10-30 02:44:51

Re: w3.org/2000/svg

#4 2022-10-30 05:28:01

Re: w3.org/2000/svg

#5 2022-10-30 07:21:04

Re: w3.org/2000/svg

phiw13 wrote #334044:

#6 2022-10-30 07:31:42

Re: w3.org/2000/svg

colak wrote #334049:

#7 2022-11-01 09:19:50

Re: w3.org/2000/svg

#8 2022-11-01 12:36:57

Re: w3.org/2000/svg

philwareham wrote #334064:

#9 2022-11-01 12:52:57

Re: w3.org/2000/svg

colak wrote #334067:

#10 2022-11-02 05:25:50

Re: w3.org/2000/svg

phiw13 wrote #334069:

#11 2022-11-02 07:49:10

Re: w3.org/2000/svg

colak wrote #334077:

Board footer