fix(ui): server-side request forgery api x-endpoint

[ptrgits]

frontend/pages/api/media-type.ts

Line 15 in bb50fc6

const response = await nodeFetch(url, { method: 'HEAD' });

frontend/ui/address/details/AddressSaveOnGas.tsx

Line 35 in bb50fc6

const response = await fetch(feature.apiUrlTemplate.replace('<address>', address));

frontend/nextjs/utils/fetchProxy.ts

Lines 55 to 59 in bb50fc6

	return nodeFetch(url, {
	...init,
	headers,
	body,
	});

Directly incorporating user input in the URL of an outgoing HTTP request can enable a request forgery attack, in which the request is altered to target an unintended API endpoint or resource. If the server performing the request is connected to an internal network, this can give an attacker the means to bypass the network boundary and make requests against internal services. A forged request may perform an unintended action on behalf of the attacker, or cause information leak if redirected to an external server or if the request response is fed back to the user. It may also compromise the server making the request, if the request response is handled in an unsafe way.

---

fix this SSRF vulnerability, we must ensure that user input cannot arbitrarily control the destination of the outgoing HTTP request. The best way to do this is to restrict the possible values of the base endpoint (i.e., the host and protocol) to a fixed allow-list of trusted endpoints. Instead of using the value of the x-endpoint header directly, we should check it against a list of allowed endpoints (e.g., from config), and only use it if it matches. Otherwise, we should reject the request or fall back to a safe default. This validation should be performed in pages/api/proxy.ts where the endpoint is selected, before constructing the URL. The rest of the code can remain unchanged, as the taint is stopped at the source.

Steps:

• Define an allow-list of permitted endpoints (hostnames or full URLs) in pages/api/proxy.ts.
• When reading x-endpoint, check if its value is in the allow-list.
• If it is, use it as the base; otherwise, use the default endpoint or reject the request.
• Do not allow arbitrary user input to control the base URL.

The best way to implement this is to add a validation step in AddressSaveOnGas before making the fetch request. If the address is invalid, the function should return early or throw an error. This change should be made in ui/address/details/AddressSaveOnGas.tsx, specifically in the queryFn function where the fetch is performed.

The changes should be made in pages/api/media-type.ts:

• Before making the request, parse the URL and check its hostname against an allow-list.
• If the hostname is not allowed, log the attempt and return an error response.
• Add any necessary imports (e.g., URL from the standard library).

References

SSRF
CWE-918

Checklist for PR author

• I have tested these changes locally.
• I added tests to cover any new functionality, following this guide
• Whenever I fix a bug, I include a regression test to ensure that the bug does not reappear silently.
• If I have added, changed, renamed, or removed an environment variable
  • I updated the list of environment variables in the documentation
  • I made the necessary changes to the validator script according to the guide
  • I added "ENVs" label to this pull request

[tom2drum]

The main characteristic of this resource is that we do not know the domain of the server that serves the asset in advance. Therefore, we cannot determine the allowed hostname array at all.

[tom2drum]

This resource is not used in production, so the changes are not necessary. If we want to keep them, please add all available API endpoints to the list.

[tom2drum]

And I don't see how this resource can be requested using the endpoint from user input.

[tom2drum]

I believe that if the address is invalid, the page will throw a 422 error, so this code will never execute.