Bug #102438
closedCSP-Errors after update to 12.4.8
100%
Description
After updating from 12.4.7 to 12.4.8, I am getting CSP error messages, which means that my integrated JavaScripts are no longer running correctly.
I have noticed this behaviour in Fluid with '<f:asset.script useNonce="true"', with the TypoScript integration includeJS(Footer) and via reloaded content from a GoogleMaps integration. All three work correctly after downgrading to version 12.4.7.
If I use Fluid with '<f:asset.script nonce="{f:security.nonce()}"', the integration works without CSP error messages. Of course, this does not work with the GoogleMaps plugin.
Is there anything else I need to set in the CSP config with the new version?
Updated by Gerrit Code Review 9 months ago
- Status changed from New to Under Review
Patch set 1 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/81841
Updated by Michael Binder 9 months ago
I think the problem is that the call $this->setNonce(new ConsumableNonce($value));
in the function updateState
in typo3/cms-core/Classes/Page/PageRenderer.php
is no longer set directly as a value with the ConsumableString
as before, but is first encoded with base64urlEncode.
I have written a patch that only uses base64urlEncode if there is no nonce. Otherwise, the nonce may no longer fit.
With the patch all my error cases are fixed.
Updated by Oliver Hader 9 months ago
Can you please provide the CSP error message shown in the browser console?
Updated by Benjamin Robinson 9 months ago
- Related to Bug #102460: Incorrect CSP nonce on additional steps and the confirmation message of the form added
Updated by Gerrit Code Review 9 months ago
Patch set 2 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/81841
Updated by Gerrit Code Review 9 months ago
Patch set 1 for branch 12.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/81893
Updated by Oliver Hader 9 months ago
- Related to Task #101751: Use ConsumableNonce instead of blunt Nonce in CSP context added
Updated by Oliver Hader 9 months ago
· Edited
Almost merged. I'm confirming it was a regression of #101751
Updated by Michael Binder 9 months ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 659d1c758c5a0d3d4a2a562ed7359a386167ad32.
Updated by Emil Angelov 9 months ago
As I've discovered and fixed the issue separately, I just wanted to mention that you may want to consider a fix that truly prevents double base64 encoding by checking whether the provided value is a valid base64 string. Here is a complete example:
if ($nonce === null || strlen($nonce) < self::MIN_BYTES) {
$this->b64 = StringUtility::base64urlEncode(random_bytes(self::MIN_BYTES));
// Prevents double base64 encoding
} elseif (base64_decode(strtr($nonce, ['-' => '+', '_' => '/']), true)) {
$this->b64 = $nonce;
} else {
$this->b64 = StringUtility::base64urlEncode($nonce);
}
For consistency reasons, you would probably want to extend TYPO3\CMS\Core\Utility\StringUtility::base64urlDecode
with a second boolean parameter called $strict and then pass it to the built-in PHP base64_decode.
Updated by Oliver Hader 8 months ago
I've created a new issue for the strict base64urlDecode
→ https://forge.typo3.org/issues/102620
Updated by Oliver Hader 8 months ago
- Related to Task #102620: Add strict parameter to base64url decode added