Bypass of RSW file_managed access protection and arbitrary HTTP HEAD reqeusts

Problem/Motivation

This issue was previously raised with the Drupal Security Team in SDO 1715391 NOTE: This is a private security tracker, only members of the Security Team and individuals who have been added will be able to access this link. Do not report Access Denied errors.

It has been decided by the Security Team that vulnerabilities that require a valid itok, $settings['file_additional_public_schemes'] = ['example']; or $config['image.settings']['allow_insecure_derivatives'] = TRUE are not entitled to private disclosure and resolution.

Due to #3298701: ImageStyleDownloadController routes do not limit schemes served It is possible to use a Core ImageStyle route to both bypass the RemoteImageStyleDownloadController managed file access checks and to force the remote_stream_wrapper to arbitrarily generate HTTP HEAD requests against remote servers and potentially act as an open proxy client for image files.

Assuming a file was published and a user has an itok:
They may use the ITOK to generate unlimited HTTP HEAD requests against a remote server. This could lead to an (automated) ban by remote hosts including hosts that no longer have published as ITOK's can only be expired by changing the Drupal Salt hash.

Assuming that allow_insecure_derivatives=TRUE and (in systems protected by CORE SA 2022-012) http/https is added to file_additional_public_schemes:
An ITOK is never required.
Remote Stream Wrapper becomes an open-proxy for image files.
With the changes for SA 2022-012 this is much less likely to occur than it was previously.

Steps to reproduce

Testing for the scenario of secure derivatives required and the file is no longer in file_managed.

Using ImageStyle->buildUrl() obtain the URL with ITOk for a publicly available image such as the Drupal wordmark logo https://www.drupal.org/files/drupal-wordmark.png
This url should be in the form of http://example.org/sites/default/files/styles/https/www.drupal.org/files...
Load the URL and observe the file is not returned as it is not in the managed_file table
Convert the url to use the image.style_private route, in the case of the above example that would be http://example.org/system/files/styles/https/www.drupal.org/files/drupal.... Visit the link and observe the file is streamed by Drupal and that a derivative has been stored on the server.

The above steps apply for when secure derivatives are not required, however in those cases the ITOK is not required.

Proposed resolution

Resolve the issue in core, see #3298701: ImageStyleDownloadController routes do not limit schemes served
Block the core(and all contrib module) provided routes from serving derivatives for RSW provided schemes. See #3298703: Core ImageStyleDownloadControler allow DoS for s3fs. for a possible sample)
A caching layer #189622: should be able to select temp directory could prevent a large number of HEAD requests from reaching a remote server.

Remaining tasks

Determine patch method

User interface changes

None

API changes

None

Data model changes

None