esc_url_raw misleading documentation, security/SSRF risk

[mal-tee]

Issue Description

The documentation for the URL sanitizer function "esc_url_raw" (https://developer.wordpress.org/reference/functions/esc_url_raw/) states that "The resulting URL is safe to use in database queries, redirects and HTTP requests.".

This is untrue! The output can not be used for HTTP requests, otherwise devs will introduce a Server-Side-Request Forgery vulnerability in their code!

A proper defense would require a lot more checks than those provided by this function, i.e. proper allow listing, DNS pinning, etc.

Furthermore, since the function defaults to wp_allowed_protocols(), a lot of protocols are allowed. There is also no validation on the host or query components. Since gopher is allowed by default, attackers can use it to smuggle content to other protocols like SMTP, see e.g. https://www.silentrobots.com/ssrf-protocol-smuggling-in-plaintext-credential-handlers-ldap/

URL of the Page with the Issue

https://developer.wordpress.org/reference/functions/esc_url_raw/

Section of Page with the issue

https://developer.wordpress.org/reference/functions/esc_url_raw/#more-information

Why is this a problem?

I've encountered applications using this function as the only sanitization step for a HTTP request. This makes them vulnerable.

PoC

nc -l 22

<?php
require_once('wp-load.php');

$result = esc_url_raw("https://fbi.com:22/maliciousdata");
echo $result;
file_get_contents($result);

3. Execute the script and observer that a request is made to localhost on port 22.

As of today fbi.com resolves to localhost. I.e. this request hits localhost. If something is running on localhost it can be accessed through PHP/Wordpress, even if a firewall shields it from the outside.

Please note that this is a very simple PoC to prove that the sanitize function is unable to sanitize against SSRF attacks and therefore should not be recommended for the HTTP request use case. A real exploit depends on the type of attack an attacker wants to perform/which services he wants to exploit on the internal network.

Suggested Fix

• Don't state that this function can be used as a sanitizer for HTTP requests.
• Warn developers to not use this function as their only sanitizer for HTTP requests, as they will be vulnerable to SSRF otherwise
• Link to common prevention and educational guides, like the OWASP cheat sheet (https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/)

[github-actions]

Heads up @WordPress/docs-issues-coordinators, we have a new issue open. Time to use 'em labels.

[github-actions]

Heads up @stevenlinx - the "code reference" label was applied to this issue.

[stevenlinx]

1.)
Thank you for filing.

I've made the following revision :

original content:
"The resulting URL is safe to use in database queries, redirects and HTTP requests."

revised content:
"The resulting URL is safe to use for database queries and redirects.

Please do not use this function as the only sanitizer for HTTP requests, as this function is unable to sanitize against security attacks such as SSRF."

However, for the link to OWASP cheat sheet, since in Make Doc, we have an External Linking Policy and this link isn't on the whitelist so it couldn't be added.

2.)
@dd32 , may I request feedback on this ticket? Thank you.