Curl is vulnerable to SSRF due to improperly parsing the host component of the URL compared to other URL parsers and the URL living standard.
curl -sD - -o /dev/null "http://google.com:80\\@yahoo.com/"
Curl makes a request to yahoo.com
instead of google.com
.
To quote the standards body issue:
> Specifically the authority state deals with parsing the @ properly. However as you’ll notice if it encounters the \
beforehand, it’ll go into the host state and reset the pointer at which point it won’t consider google.com:80\\
auth data for yahoo.com
anymore.
const whatwg_url = require('whatwg-url'); // Created by the RFC maintainers
const theUrl = new whatwg_url.URL("https://google.com:80\\\\@yahoo.com/");
const theUrl2 = new whatwg_url.URL("https://google.com:80\\@yahoo.com/");
const nodeUrl = new URL("https://google.com:80\\\\@yahoo.com/");
const nodeUrl2 = new URL("https://google.com:80\\@yahoo.com/");
console.log(theUrl.hostname); // Prints google.com
console.log(theUrl2.hostname); // Prints google.com
console.log(nodeUrl.hostname); // Prints google.com
console.log(nodeUrl2.hostname); // Prints google.com
If another library implementing the URL standard is used to white/blacklist a request by host but the actual request is made via curl or the curl library, an attacker can smuggle the request past the URL validator thus allowing an attacker to perform SSRF or an open redirect attack.