[LiveComponent] Allow specifying a live-component specific secret which defaults to kernel.secret

[dkarlovi]

Allowing to specify a LiveComponent specific secret which, (if not specified, defaults to kernel.secret) would increase the security of the feature.

Namely, one use case we had is we wanted a Node app to be able to render correct live component blocks. To do that, it needs to share the key with Symfony's LiveComponent implementation to generate the signatures which get verified by Symfony for it to work. We'd prefer to not have to share the kernel.secret with the node app (even though it's internal and built by us, trusted) because that provides ways to attack the Symfony app in other ways (login links, RCE via fragments) assuming it leaks.

Simply making this secret configurable would improve the security overall because the secret would then have a tiny scope (only that one specific thing) and be intended to be shared with the Node collaborator.

A similar thing was done somewhere on Symfony main repo by @nicolas-grekas recently (login links?)

[WebMamba]

I think this is already implemented in see: #2251

[dkarlovi]

AFAIK this is unrelated to CSRF, it's https://github.com/symfony/ux/blob/2.x/src/LiveComponent/src/Util/FingerprintCalculator.php and

ux/src/LiveComponent/src/LiveComponentHydrator.php

Lines 347 to 353 in dec3eb3

	private function calculateChecksum(array $dehydratedPropsData): ?string
	{
	// sort so it is always consistent (frontend could have re-ordered data)
	$this->recursiveKeySort($dehydratedPropsData);
	return base64_encode(hash_hmac('sha256', json_encode($dehydratedPropsData), $this->secret, true));
	}

[smnandre]

o do that, it needs to share the key with Symfony's LiveComponent implementation to generate the signatures which get verified by Symfony for it to wor

Warning: keep in mind all this is internal, and we won't support actively anything external. Especially related to encryption.

It's enough to maintain code here, we cannot officially support external usage / extension point like this. So you should not take anything about encryption / secrets / etc in the codebase for granted.

It can (and it will) change.

Simply making this secret configurable would improve the security overall because the secret would then have a tiny scope (only that one specific thing)

Can you find the change you mentioned in the core ? It's an interseting idea

[dkarlovi]

It can (and it will) change.

I'm aware, we have a small test which is checking the value calculated by Symfony matches the one calculated by Node.

Can you find the change you mentioned in the core ?

symfony/symfony#56840

[smnandre]

Ok! 👌

[smnandre]

Thank you @dkarlovi

First step here #2461

Second one here #2462

:)