To me this is the same as
--proxy-header "X-Test: hello" --proxy-header "X-Evil: owned" curl --proxy-header "X-Test: $UNTRUSTED_USER_INPUT"Lets ask the question reversed: How did people know in the first place what kind of string they need to give to --proxy-header?
Sure, but so is safety engineering. Making mechanisms more obvious to use correctly or fail safe if used incorrectly improves outcomes when flawed human beings use them. It also makes them more pleasant to use in general.
Besides, look at the man page in question. It's talking about this in terms of encoding niceties and doesn't even spell out the possibility of deliberate, let alone malicious multiline values:
"curl makes sure that each header you add/replace is sent with the proper end-of-line marker, you should thus not add that as a part of the header content: do not add newlines or carriage returns, they only mess things up for you."
That's inducing a wrong/incomplete mental model of how this parameter works.
It does for me, as any kind of extra newlines results in a multi-line string.
> ... malicious ...
Like Daniel said, garbage in, garbage out. If you pass user inputs to curl, one should check what curl does with these values and take proper care.
I disagree, but I would say that curl might as well add this as a validation check than a documentation warning.
One of the reasons we still allow that is that this "feature" was used quite deliberately by users in the past and I have hesitated to change that for the risk that it will break some users use cases.But that could just contain the bad header only, could it not?
That said, this would be a (reverse) proxy vulnerability, not one in curl.
The only way this would do something unexpected (and not necessarily dangerous besides breaking the service) would be if the curl command would be used in a scenario like: (1) curl is used by some script to access some API or other URL, (2) a user can configure the script to give a specific value to an header, let's say an authentication token or similar, but the user can't directly alter the curl command (e.g. because they can only change URL and TOKEN with a web interface). Here the user would be able to add an header IF the script is not properly sanitizing the input (so the supposed security issue IMHO would be in the script), but if adding an additional header breaks security, the underlying system has a problem too...
In a very far-stretched scenario, one can possibly add two CRLFs and have the rest of the header (if any) considered by the server as data. IF the request is a POST/PUT/... request, and IF the server returns (or allows later access to) the data, and IF the attacker manipulating the supposedly-restricted single-header can see the output of the call (or retrieve the saved data), then we'd have an information disclosure issue. Would it disclose anything sensitive? Not sure, unless there's an auth token or something AFTER the header. And again, I'd rather incriminate the curl caller for not sanitizing the input if this happens.
blueflow•1mo ago