undefined - Contrib.social

🇨🇦Canada gapple

The test includes a couple keys previously supported by core, but not an unknown key (e.g. the csp example in the issue summary)

📌 | Content-Security-Policy | Use config_target in settings form

🇨🇦Canada gapple

📌 | Drupal core | Add a default Content-Security-Policy and clickjacking defence to core

🇨🇦Canada gapple

Something that came up in #2868079: Add a default Content-Security-Policy-header for svg files → is that there may be a need for different policies in certain cases - uploaded files should probably have scripts and styles blocked, though SVGs may need inline styles, image data, and fonts. Private files can have the header applied from the event subscriber, but public files would require an addition to .htaccess.

Instead of a single set of policies, the service parameter could be keyed by use:

default:
  report_only:
  enforced: "script-src * 'unsafe-inline'; object-src 'none'; frame-ancestors 'self'"
private_files:
  report_only:
  enforced: "default-src 'none'"
svg:
  report_only:
  enforced: "default-src 'none'; style-src 'unsafe-inline'; image-src data: font-src: data:"

📌 | Drupal core | Sanitize OR add Content-Security-Policy for SVGs

🇨🇦Canada gapple

👋 CSP module maintainer here.
CSP module provides APIs for modules to amend a site's policy → . In most cases it's pretty straightforward, but gets more involved for cases where it's not just adding an additional external domain to a directive. The goal of the module is that anyone can install the module for a security improvement, that it's easily configurable for site builders to add exceptions not captured automatically (& ideally harden the default config with basic knowledge), but also flexible for developers to handle any more complex uses (and to do so safely without breaking other site functionality).
Module subscribers with the same priority will execute after core, so it's the module's responsibility to preserve/amend/replace any value previously set by core.

CSP has its own issue for applying a different policy to private files ( ✨ Provide different CSP policy for private files Active ), though there hasn't been any work done on it so far. If a special value is added to core for SVGs, then I'll update the module to match. If there's consensus on what should be added to core, I'll probably have a new release of the module before it's committed to core 🙂.
Alternately, the CSP module would be a good way to evaluate a potential solution (at least for private files, I'm not sure about the module altering htaccess), with users who have opted in to using a policy on their site. It would have to be an optional feature for the current major version, but could be enabled by default for new modules installs (and a site status message could prompt existing sites to try enabling it).

This issue for core would add a static policy that can be configured in a service parameter: 📌 Add a default CSP and clickjacking defence and minimal API for CSP to core Active
Instead of providing a single policy set, maybe it should be keyed policies to allow for additional cases (e.g. default, private-files, svg, etc, each with report-only and enforced values).

🇨🇦Canada gapple

Better description of alter priority; example of nonce & fallback

✨ | Drupal core | Enable ConfigTarget to format error messages

🇨🇦Canada gapple

🐛 | Drupal core | Fix transltion string in ConfigFormBase.php

🐛 | Drupal core | ConfigFormBase::formatMultipleViolationsMessage() return type change will cause error

🇨🇦Canada gapple

Opened 🐛 ConfigFormBase::formatMultipleViolationsMessage() return type change will cause error Active as a bug from this change.

🇨🇦Canada gapple

gapple → created an issue.

🐛 | Drupal core | Fix transltion string in ConfigFormBase.php

🇨🇦Canada gapple

Ran into an issue with the the return type change, since I was developing a module using the latest version of core and copied the new return type hint.

When using the new return type in an override with a stable version of core <=11.0.5, the child class is returning a wider type than it's parent.
When using the old return type in an override with 11.x-dev, parent::formatMultipleViolationsMessage() returns a wider type than the child class.

For a module to maintain compatibility with older versions of core and not break if it calls the parent method which now returns Markup, it will need to change the value returned from its parent:

    $parent = parent::formatMultipleViolationsMessage($form_element_name, $violations);
    if ($parent instanceof TranslatableMarkup) {
      return $parent;
    }
    else {
      // phpcs:ignore Drupal.Semantics.FunctionT.NotLiteralString
      return $this->t((string) $parent);
    }

Once the module drops support for older versions of core, it can update its typehint and remove the extra code.

\Drupal\update\UpdateSettingsForm also needs its return type updated.

✨ | Drupal core | Enable ConfigTarget to format error messages

🇨🇦Canada gapple

✨ | Drupal core | Enable ConfigTarget to format error messages

🐛 | Drupal core | If a form element mapped to a #config_target has multiple constraint violations, only the last one is displayed

🇨🇦Canada gapple

gapple → created an issue.

🇨🇦Canada gapple

The current MR would address multiple violations on a non-sequence value, but if an item within a sequence has multiple violations it looks like only the last one will be kept.

ConfigFormBase::formatMultipleViolationsMessage() also assumes it's being called on a sequence, so multiple constraint violations on a non-sequence value would still be formatted like "Entry 0: Constraint 1 message \n Entry 1: Constraint 2 message".
Forms can override the method to change the output based on the form element name in this case though.

📌 | Content-Security-Policy | Use config_target in settings form

🐛 | Drupal core | ConfigTarget::__construct() documentation references incorrect ToConfig enum name

🇨🇦Canada gapple

🐛 | Drupal core | ConfigTarget::__construct() documentation references incorrect ToConfig enum name

🇨🇦Canada gapple

Found a couple more incorrect references

🇨🇦Canada gapple

gapple → created an issue.

📌 | Content-Security-Policy | Add config validation constraint for sources

🐛 | Content-Security-Policy | Call to a member function validateForm() on null in Drupal\csp\Form\CspSettingsForm->validateForm()

🇨🇦Canada gapple

🇨🇦Canada gapple

Changes to provide a form error if an unavailable reporting plugin is referenced in config are in the 2.1.1 release.

Be sure to run module updates, and let me know if you continue to see a similar error.

✨ | Drupal core | Multiple Errors for a Single Form Element

🐛 | Content-Security-Policy | Call to a member function validateForm() on null in Drupal\csp\Form\CspSettingsForm->validateForm()

🇨🇦Canada gapple

🇨🇦Canada gapple

Is this after updating from 1.x to 2.x? Do you have a pending site update?

https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
The sitelog reporting handler was removed from 2.x in favour of the Reporting API module → , and an update will disable policy violation reporting on a directive if it has not been changed to a supported alternative.

It is still possible to better handle the configuration referencing an unavailable reporting plugin there though...

🐛 | Persistent Login | Error on hook_update_8108 uid IN ()' cannot be empty

🇨🇦Canada gapple

🤞 that's a final fix for this issue.

Just wanted to also note that the tokens in the database aren't accepted even if provided by a browser, and this cleanup is only really needed for sites with tokens configured to a permanent lifetime, so there isn't a problem if the update is not completed on a site (provided it doesn't block any other necessary updates).

🐛 | Persistent Login | Error on hook_update_8108 uid IN ()' cannot be empty

🇨🇦Canada gapple

That's odd... On the last iteration $sandbox['#finished'] = $sandbox['processed'] / $sandbox['total']; should equal 1 to complete the batch.
Are there tokens stored for the anonymous user (uid:0)? That would increase $sandbox['total'] to one more than will be returned in the $token_users queries - but that shouldn't happen so some checks might need to be added elsewhere 😬.

📌 | CSP log | Compatibility with CSP 2.0

🇨🇦Canada gapple

Didn't catch @jabeler's review before - updating to RTBC :)

Bumping priority - CSP 1.x is still the most used version at this time, but is no longer receiving feature updates.

🐛 | Persistent Login | Deleting user throws type error in loadTokenOnRequestEvent

🇨🇦Canada gapple

This is fixed in 8.x-1.9 and 2.2.3

🐛 | Persistent Login | function deleteToken(PersistentToken $token) not working

🇨🇦Canada gapple

The double-hashing was fixed in 8.x-1.7 and 2.2.1
Cleaning up tokens for deleted users was fixed in 8.x-1.9 and 2.2.3

🐛 | Persistent Login | Error on hook_update_8108 uid IN ()' cannot be empty

🇨🇦Canada gapple

Thanks for the quick patch & review :)

New patch releases should be available shortly.

🇨🇦Canada gapple

greggles → credited gapple → .

💬 | Content-Security-Policy | General strategy for misc. sources?

🇨🇦Canada gapple

📌 | Content-Security-Policy | Add config validation constraint for sources

🇨🇦Canada gapple

🌱 | Content-Security-Policy | Use Autowire & Autoconfigure for services

🇨🇦Canada gapple

📌 | Content-Security-Policy | Add config validation constraint for trusted types policies

🇨🇦Canada gapple

📌 | Content-Security-Policy | Add basic config validation constraints

🇨🇦Canada gapple

✨ | Security Kit | Implement a "semi automatic" Nonce settings

🇨🇦Canada gapple

@sokru My understanding is that whole page caching of a response with a nonce can be acceptable: https://serverfault.com/a/1064775/66144
Using a render placeholder ensures that a new nonce is sent for any request from an authenticated user or otherwise not served from the page cache, where new markup could be placed on the page but could only be aware of an outdated nonce value.

An issue with the proxy / edge cache worker example is that that using a predictable placeholder like NGINX_CSP_NONCE could allow any injected content to use that value as well and have it replaced with the valid nonce.
The current patch also has this issue, as sprintf('nonce_%s', Crypt::hashBase64(__METHOD__)) will result in a known static value. The CSP module uses a random value in its placeholder so that it's not predictable between requests, but using the site's hash_salt would would also work as a way to provide a consistent but unique and unpredictable placeholder value for a site.

✨ | Google Tag | Support Content Security Policy

🇨🇦Canada gapple

@rgpublic A hash can't be used on the external gtm or gtag js because their contents aren't known or static. The loader file could change at any time, making the hash invalid, and any additional dynamically loaded scripts won't be permitted.
The tag manager script loader will propagate the nonce to additional scripts (as verified by @chrissnyder in #12), without requiring the originating page to know the script contents (for a hash) or source domain (for non-tag manager scripts) to place in the policy.

✨ | Google Tag | Support Content Security Policy

🇨🇦Canada gapple

@berliner From the one post I've seen that's worked through the impact of full-page caching with a CSP nonce https://serverfault.com/a/1064775/66144:

Let's say you as an attacker are served the same nonce as your victim on a response to the URL /foo/bar. Now you could use this nonce in your XSS payload. Let's consider two of the most common XSS scenario's:
- URL parameter based reflected XSS: /foo/bar?payload=... will likely have a different cache key than /foo/bar, therefore causing the user to be delivered a fresh response with a new nonce. The attack fails.
- Stored XSS in dynamic HTML: your payload is now included when the user loads /foo/bar. However, if the user refreshes and gets a response from the cache, then this won't include your injected XSS payload. Alternatively, if they get a fresh response they will also get a fresh nonce. In either case the attack fails.

Now, this doesn't mean that this situation can never be exploited: for example, if /foo/bar has vulnerable JavaScript that modifies the DOM in a way that the attacker payload can be injected it might possible to use the cached nonce. Think of DOM based XSS attacks via data in the # segment of a URL or in AJAX responses.

It will be much trickier for an attacker to exploit the latter situation though, which may be sufficient since the point of CSP is to just provide defense-in-depth; it can not guarantee immunity for 100% of XSS attacks.

For Drupal, that means to not use AJAX responses to inject unsanitized markup, from user provided data, containing an inline script with a nonce attribute. This would also only be an effective attack against anonymous users on a single page for the duration of the calling page's cache lifetime, and other pages that receive the injected inline script with a nonce (and the original page when it's re-rendered with a new nonce) will send a violation report that should prompt investigation to address the underlying markup injection.

(AddJsCommand for adding new script files to the page through AJAX does not (currently) propagate the page's nonce to the new scripts, so they must be permitted by the originating page's policy through another source like 'self'.)

The CSP module includes a test that authenticated users receive a unique nonce for each request of a page that is cacheable in the dynamic page cache.

----

I've seen an approach where an edge cache worker handles replacing a placeholder value from the application, so that even responses served from the cache receive a unique nonce. But if the worker fails then responses are receiving a truly static value for all requests, and some examples I've seen have used a potentially predictable placeholder value such that markup injection would also be replaced with a valid nonce.
This would be possible with the CSP module by swapping out the Nonce service to one that responds with a static nonce value that includes some secret shared between the application and edge cache.

✨ | Drupal core | Allow additional keys in #attached