Cut the handle host at a path

[pfefferle]

I found this during the security review of #3882. For acct:, mailto: and xmpp: handles the host is taken off the string itself, and it was only cut at ? and #. So acct:user@example.com/x gave the host example.com/x: a domain block on example.com did not match, and the WebFinger lookup went to https://example.com/x/.well-known/webfinger. That lookup usually fails, so the second block check on the resolved actor URL did not catch it either.

Proposed changes:

• Webfinger::get_identifier_and_host() cuts the host at / too, like it already does for ? and #. The identifier itself is not cut.

Other information:

• Have you written new tests for your changes, if applicable?

I strip the path instead of rejecting the handle. A rejected handle has no host, and the block check treats a missing host as not blocked, so user@blocked.example/x would still get through.

The host stays after the last @. I tried wp_parse_url() instead, but it reads a local part with #, ? or / as the host (user#x@evil.com gave user) and finds no host in xmpp://guest@example.com. With the last @, user@example.com/@evil.com is looked up on evil.com, and that is also the host the block is checked against.

A port stays in the host, as before. With a valid port the lookup works, and the block check on the resolved actor URL catches a blocked domain.

Two side effects: an XMPP address with a resource part (user@host/resource) now gets the right host, and acct:application@<site>/x is accepted as the application resource, like ?x and #x already were.

Testing instructions:

• Run wp eval 'var_dump( \Activitypub\Webfinger::get_host( "acct:user@example.com/x" ) );': it returns example.com, on trunk example.com/x.
• Or run vendor/bin/phpunit --filter test_get_host_cuts_handle_suffixes.

Changelog entry

• Automatically create a changelog entry from the details below.

Changelog Entry Details

Significance

• Patch
• Minor
• Major

Type

• Added - for new features
• Changed - for changes in existing functionality
• Deprecated - for soon-to-be removed features
• Removed - for now removed features
• Fixed - for any bug fixes
• Security - in case of vulnerabilities

Message

Domain blocks now also apply to handles that have a path after the domain, like @user@example.com/x.