cURL / Mailing Lists / curl-users / Single Mail


Re: curl and http redirects; possible security implications

From: Daniel Stenberg <>
Date: Sun, 18 Apr 2010 19:44:36 +0200 (CEST)

On Sun, 18 Apr 2010, Alex Bligh wrote:

> In the use case I mentioned, the machine might be behind some form of packet
> filtering firewall which can give people a false sense of security. Whilst
> admittedly a miscreant can e.g. do a redirect to or
> similar, at least the command is always going to be prefixed by "get".

No it won't always do that, like if a HTTP server responds to a POST with a

But my main question about your telnet remark was mostly that telnet has no
way to automatically login with a password so unless the telnet server allows
logins without password that won't do much. And in general, curl's telnet
support is not too similar to how the other protocols work so I fail to see
what harm such a redirect could cause even in the worst case.

> Would you accept a patch to allow command line options
> --proto PROTOLIST
> --no-proto PROTOLIST
> --redir-proto PROTOLIST
> --no-redir-proto PROTOLIST

> where protolist is a comma separated list of protocols and/or 'all',
> and all options are evaluated left to right, starting with the
> currently allowed protocols? So, e.g.
> --no-proto all --proto http,https
> would only allow http and https.

I would indeed accept such a patch.

Bit I would prefer to see this feature limited to using onle two command line
options (we do have a very large amout already so keep it down somewhat is a
concern of mine). You could perhaps have --proto be able to reverse the
options, perhaps to say "--proto !http,ftp" to mean all protocols except http
and ftp, while --proto http,ftp would mean only http and ftp. Also, we try to
minimize how options need to be in a particular order, and your --no-proto and
--proto example above fails that.

> I'm presuming all I need do is go tweak current library variables.

Yes exactly!

List admin:
Received on 2010-04-18