TXP-4.9-dev – php header() on the admin side (CSP)

phiw13 · 2023-03-10 06:02:06

Is that expected that headers set through PHP on the admin side do not override headers set server side (e.g. .htaccess)? At best they sort-of complement them.
I am playing locally with the CSP headers provided by core. The browser console reports many errors, what turns out to be due to having a (test) CSP policy set at the server level.

If that is expected, that would be annoying, and I would have to review how to handle a CSP policy for the public side.

–^–

A related question
The CSP policy for the admin side, relies on {TEXTPATTERN_CSP_NONCE} (e.g. here). Is that equally accessible from the public side?

if so, how?

I imagine setting that as variable and passing it to the various asset-links / script & style blocks and set the CSP header through <txp:header />.

etc · 2023-03-10 12:53:26

phiw13 wrote #334998:

Is that expected that headers set through PHP on the admin side do not override headers set server side (e.g. .htaccess)?

Good question. I’d say txp headers should override what is already set, but it depends on whether admins prefer edit config.php or .htaccess. To debate.

Bloke · 2023-03-10 13:27:31

Yeah, a tough one. There are also issues when using -src-attr directives on the admin side, as defined in the commented-out code you linked to. That nobbles things like the Save process on most panels so we probably need to revisit the CSP handling a little and tweak it before we let 4.9.0 out the door.

phiw13 wrote #334998:

The CSP policy for the admin side, relies on {TEXTPATTERN_CSP_NONCE}… Is that equally accessible from the public side?

No, it’s not exposed on the public site. Just curious why you would need the same nonce on the admin side and public sides, rather than creating a new one of your own via PHP, e.g.:

base64_encode(Txp::get('\Textpattern\Password\Random')->generate(24));

What’s your use case?

Incidentally, I have an unreleased minuscule plugin called smd_token to generate tokens via a tag, and it’s ludicrously simple:

/**
 * Public tag: generate a random token.
 *
 * @param  array  $atts  Tag attributes
 * @param  string $thing Tag container content
 * @return string        HTML
 */
function smd_token($atts, $thing = '')
{
    extract(lAtts(array(
        'length' => 16,
        'prefix' => '',
    ), $atts));

    $token = Txp::get('\Textpattern\Password\Random')->generate($length);

    return $prefix.$token;
}

If something like that would be a useful addition to core as a built-in tag, I’m sure we could come up with something similar, or perhaps even more generic where you could pick the algorithm and output encoding and stuff like that to return a cryptographic hash to be used however you like on your sites.

Last edited by Bloke (2023-03-10 13:28:38)

phiw13 · 2023-03-10 23:41:55

etc wrote #335007:

Good question. I’d say txp headers should override what is already set, but it depends on whether admins prefer edit config.php or .htaccess. To debate.

Well, from observation (in the CSP header case): the domain.tld/.htaccess rule (Header set Content-Security-Policy) overrides the header send via TXP/PHP (set in config.php, based on the example).

I would want the TXP/PHP set one to win…

phiw13 · 2023-03-10 23:51:13

Bloke wrote #335014:

No, it’s not exposed on the public site. Just curious why you would need the same nonce on the admin side and public sides, […]

What’s your use case?

If the .htaccess CSP header set for the domain/public side overrides the config.php CSP header set for admin side, then I need to figure out a different strategy for the public side – as for example set a CSP policy via PHP headers.

Incidentally, I have an unreleased minuscule plugin called smd_token to generate tokens via a tag, and it’s ludicrously simple:

/**...

If something like that would be a useful addition to core as a built-in tag, I’m sure we could come up with something similar, or perhaps even more generic where you could pick the algorithm and output encoding and stuff like that to return a cryptographic hash to be used however you like on your sites.

That might indeed be an interesting and useful addition to the core tags.

I‘ll have a look at your plugin next week. Thanks for that.

–^–

PS – I am very far away from deploying the 4.9.0 strict-CSP header approach for the admin side – too many admin side plugins break down…

etc · 2023-03-11 11:12:53

It looks difficult to override Apache headers via PHP. The only option that worked for me is using setifempty instead of set in .htaccess. In this case, headers can be set by <txp:header /> or header() function.

phiw13 · 2023-03-12 01:26:18

etc wrote #335041:

The only option that worked for me is using setifempty instead of set in .htaccess.

Thanks! I did not know about setifempty. Will try that out.

phiw13 · 2023-03-13 02:50:39

setifempty works indeed! I can set a .htaccess based CSP header for the public side and a strict CSP though PHP headers for the admin side. One step forward.

Header setifempty Content-Security-Policy "your policy here;"

Bloke wrote #335014:

There are also issues when using -src-attr directives on the admin side, as defined in the commented-out code you linked to. That nobbles things like the Save process on most panels so we probably need to revisit the CSP handling a little and tweak it before we let 4.9.0 out the door.

What issues are you seeing during the Save process? Testing on the Write panel does not reveal any issues –currently…– and the Save process is successful, both new article and edit older article. I had to disable the 2 plugins I have that affect that panel but then the console was clear the whole time (Safari & Brave, Firefox seems to complain randomly about the theme stylesheet but everything is working correctly.

–^^–

Now… where is that magic pixie dust that automatically fixes all plugins… ?

Bloke · 2023-03-13 08:01:08

phiw13 wrote #335059:

What issues are you seeing during the Save process?

With these headers set:

$headerCsp =
    "base-uri 'none';".
    "block-all-mixed-content;".
    "connect-src 'self';".
    "default-src 'none';".
    "font-src 'self';".
    "form-action 'self';".
    "frame-ancestors 'self';".
    "img-src data: 'self';".
    "media-src 'self';".
    "script-src 'self' 'unsafe-inline';".
    "script-src-attr 'none';".
    "script-src-elem 'self' 'nonce-{TEXTPATTERN_CSP_NONCE}';".
    "style-src 'self' 'unsafe-inline';".
    "style-src-attr 'unsafe-hashes' 'sha256-aqNNdDLnnrDOnTNdkJpYlAxKVJtLt9CtFLklmInuUAE=';".
    "style-src-elem 'nonce-{TEXTPATTERN_CSP_NONCE}';".
    "worker-src 'none'";
define('CONTENT_SECURITY_POLICY', $headerCsp);

I get no green success messages when saving or publishing articles. Console complains about script-src-style and script-src-elem bring blocked. Firefox.

This was a few months ago though, so maybe things have changed since

phiw13 · 2023-03-13 09:10:42

Bloke wrote #335061:

I get no green success messages when saving or publishing articles. Console complains about script-src-style and script-src-elem bring blocked. Firefox.

This was a few months ago though, so maybe things have changed since

Works fine now, as far as I can tell (Firefox 111beta). The only thing I see (Firefox only) is multiple console messages complaining about the stylesheet- but everything loads correctly.

Content Security Policy: The page's settings blocked the loading of a resource at http://txpdev.local/textpattern/admin-themes/hive/assets/css/textpattern.css ("style-src-elem").

I have no clue what is eventually being blocked. An icon? Safari and Brave have no issue there.

Textpattern CMS

Textpattern CMS support forum

#1 2023-03-10 06:02:06