Re: CGI.pm and the untrusted-URL problem

[kragen () POBOX COM (Kragen Sitaker)]

Lincoln Stein writes:
> The important point is that anything coming from the outside -- the
> URL, the SERVER_PROTOCOL, the request body, the request MIME type --
> should be treated as untrusted data.  If you turn on taint checking,
> Perl will refuse to take "dangerous actions" with untrusted data or
> any data that has touched untrusted data.  Modifying CGI.pm to be more
> strict with the URL has the unwanted consequence of breaking people's
> scripts and generating lots of support messages to me, without making
> the CGI script any safer.
>
> Even if you have a Web browser that is "good", people can still telnet
> to the web server and make illegal requests.

I agree; making modifications to reduce functionality is, in general, a
bad thing, and we all know you have more than enough support messages
to answer as it is --- particularly considering you're doing it out of
the goodness of your heart, and get little thanks for it.  (Thanks!)

I think you may find, though, that this particular instance is not as
it seems; if you look closely at the modification I suggested, you will
see that it affects only the "scheme" part of the URL, which is almost
always "http" or "https".

I have compiled a list of all the URL schemes presently in use or
proposed for future use [0]; none of them would be affected by this
patch.  Since new URL schemes are proposed only very infrequently, and,
to my knowledge, CGI scripts are only used with two or three of them, I
think this particular change is likely to never cause a single email to
be sent to you.

Also, I think the problem you're answering might be different from the
problem I meant to report; the issue I was thinking of was not that the
web server trusts the web browser --- it doesn't --- but that the
browser/server system trusts the URL.  I think that taint checking
becomes somewhat less useful in this case.  (The script I was testing
when I found the problem had taint checking turned on.)

Even a script carefully written to avoid the problem described in CERT
Advisory CA-2000-02, knowing that the URL may not be supplied by the
client it's talking to, can succumb to this problem.  SERVER_PROTOCOL
can, of course, be specified by the Web server (and, with some Web
servers, even by the client), but it is surprising that it can be
specified by a third party, other than the client or server.

If someone takes special measures, such as telnetting to the server, to
send a malformed HTTP request, they presumably know whether the result
will contain e.g. malicious cookies or malicious JavaScript, because
they put it there.  But if a third party supplies a URL that will cause
their lenient client to send a malformed HTTP request, they may not be
so cautious.

[0] http, ftp, file, mailto, news, cid, telnet, rlogin, tn3270,
        javascript, about, webtv, https, gopher, lynxprog, wais,
        nntp, snews, newspost, newsreply, snewspost, snewsreply,
        finger, cso, lynxexec, lynxcgi, LYNXHIST, LYNXKEYMAP,
        prospero, whois, webster, acap, afp, afs, callto, chttp,
        clsid, data, date, DAV, fax, gsm-sms, h323, h324, hdl, hnews,
        iioploc, ilu, imap, IOR, irc, isbn, java, javaRMI, jdbc,
        ldap, lifn, livescript, lrq, mailserver, md5, mid, mocha,
        modem, tel, nfs, opaquelocktoken, path, phone, pop, pop3,
        printer, res, rtsp, rvp, rwhois, rx, sdp, service, sip, shttp,
        STANF, t120, telephone, tip, tv, uuid, urn, vemmi, videotex,
        view-source, whois++, z39.50r, z39.50s.  Of these, only a fraction
        are actually registered or in widespread use; see
        ftp://ftp.isi.edu/in-notes/iana/assignments/url-schemes,
        http://www.w3.org/Addressing/schemes, and
        http://www.crl.com/~subir/lynx/lynx_help/lynx_url_support.html

--
<kragen () pobox com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either.  :)