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 -- <kragenat_private> 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. :)
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:35:04 PDT