Real-time collaboration awareness state can be mutated by another authorized user

[czarate]

During collaborative sessions, awareness state is set by each participating client. Awareness state includes general information such as the user's display name and avatar URL. It also includes presence information such as their current cursor position. This state, once shared with other clients, is used to render indicators that show their presence and activity in the session.

Using the built-in HTTP polling sync server, awareness state is accepted and stored after the user is authorized. This state is keyed against their sync client ID, which is randomly generated.

However, nothing prevents a user from spoofing another client's client ID, which is discoverable by inspecting network responses. By replaying a sync request with a different client ID, they could temporarily overwrite another client's awareness state. I say "temporarily" because the spoofed client will soon send another awareness update that will restore it.

Trac ticket: https://core.trac.wordpress.org/ticket/64782

Using the built-in HTTP polling sync server, awareness state is accepted and stored after the user is authorized. This state is keyed against their sync client ID, which is randomly generated.

However, nothing prevents a user from spoofing another client's client ID, which is discoverable by inspecting network responses. By replaying a sync request with a different client ID, they could temporarily overwrite another client's awareness state.

This change prevents this spoofing by storing and checking the user's WordPress user ID to ensure it matches the initial update.

Backport of ​https://github.com/WordPress/gutenberg/pull/76056

[ellatrix]

In 61838:

Real-time collaboration: check wp_user_id before accepting awareness update.

Using the built-in HTTP polling sync server, awareness state is accepted and stored after the user is authorized. This state is keyed against their sync client ID, which is randomly generated.

However, nothing prevents a user from spoofing another client's client ID, which is discoverable by inspecting network responses. By replaying a sync request with a different client ID, they could temporarily overwrite another client's awareness state.

This change prevents this spoofing by storing and checking the user's WordPress user ID to ensure it matches the initial update.

Developed in: ​https://github.com/WordPress/wordpress-develop/pull/11120.
Syncs: ​https://github.com/WordPress/gutenberg/pull/76056.

Fixes #64782.
Props czarate.

[dd32]

I'm seeing this warning being triggered on WordPress.org thousands of times per 5 minutes:

E_WARNING: Undefined array key “wp_user_id” in wp-includes/collaboration/class-wp-http-polling-sync-server.php:194

It looks like $entry is:

array (
  'client_id' => 1583....,
  'state' =>
  array (
  ),
  'updated_at' => 1772759838,
)

or

array (
  'client_id' => 6209....,
  'state' =>
  array (
    'collaboratorInfo' =>
    array (
      'avatar_urls' =>
      array (
        24 => 'https://secure.gravatar.com/...',
        48 => 'https://secure.gravatar.com/...,
        96 => 'https://secure.gravatar.com/...',
      ),
      'browserType' => 'Chrome',
      'enteredAt' => 1772748369812,
      'id' => 227158,
      'name' => 'User Name',
      'slug' => 'userlogin',
    ),
  ),
  'updated_at' => 1772759838,
)

Edit: This is likely only due to running the previous version of the code in production. If this can't be reproduced by others, then please re-close this ticket as fixed. Do not add extra workarounds for it.

[peterwilsoncc]

Replying to dd32:

I'm seeing this warning being triggered on WordPress.org thousands of times per 5 minutes:

E_WARNING: Undefined array key “wp_user_id” in wp-includes/collaboration/class-wp-http-polling-sync-server.php:194

...

Edit: This is likely only due to running the previous version of the code in production. If this can't be reproduced by others, then please re-close this ticket as fixed. Do not add extra workarounds for it.

It is indeed due to running a previous beta in production.

I was only able to reproduce it wit the following steps:

1. Checkout Beta 2
2. Start and save a post, leaving the editor open after saving.
3. Checkout Beta 3
4. Error occurs and frequently. A dialog is shown in the editor that the user is disconnected.

If I closed the editor in step two, and reopened it after upgrading I did not receive any errors. For WordPress.org the errors should settle down once authors return to the post editors they've left open and close them due to the error message.

I'll re-close this as fixed as it doesn't warrant a workaround.