Lethargic Man (anag.)

Anyone offering "CGI" is almost certain to offer Perl.

Perl's taint mode is neither necessary nor sufficient; i.e. you can do without it (and many do), and even if you do use it you don't have any guarantee of security (you do have a guarantee of inconvenience, though).

You should think about how data you are passing across any interface will be interpreted. For instance anything you pass to the single-arg form of system will be treated as a shell command, with all the interesting bits of syntax that implies. You don't want your users to be able to insert a raw ; or ``, or any of a number of other characters, into a shell command you execute.

There are several approaches to dealing with this kind of thing. The two main ones are sanitization and quoting. The former means limiting the set of characters passed to those known to be safe: that is to say you remove or reject all characters not known to be safe. The latter means passing any character but quoting it appropriately for the interface in question so that the shell (or whatever) will not treat it as starting a new command or something. In the case of shell commands Perl's \Q operator is handy here.

I prefer the quoting approach, but both have their place.

(Hopefuly you've noticed that I've phrased things in terms of rejecting/removing/quoting characters not known to be safe, rather than rejecting those known to be unsafe.)

You should understand the interfaces you use. In Perl system is an obvious danger point as is ``; but open can take shell commands too, so if the caller has any influence at all over choice of filenames then you must be incredibly careful - if the client controls the first or last character of the “filename” for instance then they can potentially arrange for the command of their choice to be executed. Another trap with user-controlled filenames is using .. to escape into a parent directory - perhaps via a child directory! - and access some file that ought not to be available.

Changes of encoding used to be a classic source of error - e.g. decoding URL-encoding twice. Re-emitting input data to output without suitable SGML (or whatever) quoting is very another common error (a problem with this being that it lets an attacker “run” arbitrary HTML, perhaps with embedded scripts, with the victim's privileges, provided they can trick the victim into visiting a carefuly chosen URL). Format strings vulnerabilities (where you let the user control the first arg to printf or similar) are more commonly found in C programs, and probably aren't as evil in Perl as in C, but could in principle at least cause problems in Perl programs.

The idea of taint checking is that every bit of data received from an “untrusted” source is marked as tainted and any attempt to pass it across an interface where a badly chosen value could cause unexpected effects provokes an error. There are rules about which operations keep and lose the taint. I'm not really a fan of this approach myself, and it's noticable that taint checking seems to be very rarely used - I think in practice it's just not as useful as it sounds.

About the one thing you don't have to worry about in Perl are buffer overruns. But there are a large number of other potential disasters.

From:

(Hopefuly you've noticed that I've phrased things in terms of rejecting/removing/quoting characters not known to be safe, rather than rejecting those known to be unsafe.)

Well I certainly have now. :o)

About the one thing you don't have to worry about in Perl are buffer overruns. But there are a large number of other potential disasters.

Ulp. Maybe I'll get someone with knowledge of insecurities to look over my scripts once I've written them.

But thanks for your advice anyway!

From:

I find taint checking very useful. It's not foolproof, but it is good at enforcing discipline (rather than providing security in itself) and keeping an eye on where variables have come from. Apart from that, I agree with your comments.

I'd also suggest reading up a little about SQL injection attacks if you're using any databases as a back-end to anything.

From:

Okay, I've now going through my taint-safe forms checking they're otherwise secure, and I've a few more questions.

You should think about how data you are passing across any interface will be interpreted. For instance anything you pass to the single-arg form of system will be treated as a shell command, with all the interesting bits of syntax that implies. You don't want your users to be able to insert a raw ; or ``, or any of a number of other characters, into a shell command you execute.

Okay, my scripts are doing one of two things with their input. I have one script which uses the CGI params passed to it (by other links on the site) to call an off-site URL (what it's doing is rebranding a Yahoo Calendar to fit the site). This merely passes the parameters on to a LWP::UserAgent call to Yahoo, and reports them back to the user in the form of a link to the linked-to site. I would imagine this does not need protecting, as the user could not get control of anything here bar what is passed on to the Yahoo site.

The other thing I'm doing is parsing a webform by substituting the filled in field values and emailing it on (with fixed email headers) as an HTML page. Here I strip out angle brackets and script tags before sending it on. I'm using Mailer::Sender (actually Mailer::Sender::Easy), which connects direct to the mail server via a socket, to do the mailing. Do you know what the vulnerabilities of this are? Do I need to do any further substitution, like you suggest above; or worry about anything that this might do, in re buffer overruns or anything?

One of my webforms allows uploading of a file. I'm using code I found on the Web (http://perlmeme.org/tutorials/cgi_upload.html) to do so in a taint-safe manner, but is there anything else I should worry about in this regard?

From:

Isn't that against the Yahoo TOS? That sort of thing usually is.

As for the webform, it'll depend on how you're parsing the input. Better than stripping out known bad stuff is only allowing known good stuff.

Perl doesn't tend to have buffer-overrun problems very much, its problems are much more to do with its tendency to eval all sorts of things.

From:

Isn't that against the Yahoo TOS? That sort of thing usually is.

Depends how anal they're being, I suppose. It's no different, really, from presenting a syndicated RSS feed that looks different to its originating page (which I'm also doing). It's not that I'm trying to pass off Yahoo's work as my own: I'm providing a link to the original site, and including the Yahoo copyright notice, complete with hyperlinks to the terms of service and privacy policy.

Where do you draw the line? If you regard that as not okay, what if I'd got Yahoo's site in a frame on another site, with other content around it? Or an iframe?

OTOH, maybe I should get advice on this before I make the site live...

From:

The main question is probably if you're stripping out their advertising.

From:

There is no advertising on the main Yahoo calendar page, just links to other parts of Yahoo.

From:

Isn't that against the Yahoo TOS? That sort of thing usually is.

This is crazy. I've just been looking at the ToS for Blogspot, and Flickr, which I shall also be remunging in this way. The Blogspot ToS (http://www.blogger.com/terms.g) state:

11. Pyra PROPRIETARY RIGHTS You acknowledge and agree that the Service and any necessary software used in connection with the Service ("Software") contain proprietary and confidential information that is protected by applicable intellectual property and other laws. [...] Except as expressly authorized by Pyra or advertisers, you agree not to modify, rent, lease, loan, sell, distribute or create derivative works based on the Service or the Software, in whole or in part.

Which seems clear enough... and yet they provide an Atom feed for each blog, which expressly seems to encourage such behaviour! Moreover the ToS are not referenced in the Atom feed XML (http://maromuk.blogspot.com/atom.xml) or the "About Atom feeds"</>A page, nor do the ToS refer to syndication at all!

With Flickr, it's even crazier. Flickr's been bought by Yahoo. The Flickr ToS (http://www.flickr.com/terms.gne) page links to both Flickr's and Yahoo's ToS. The Flickr page says
The Flickr service makes it possible to post images hosted on Flickr to outside websites. This use is accepted (and even encouraged!). However, pages on other websites which display images hosted on flickr.com must provide a link back to Flickr from each photo to its photo page on Flickr.
However, the Yahoo ToS (http://docs.yahoo.com/info/terms/)—the same as started off this subthread—say:
17. YAHOO!'S PROPRIETARY RIGHTS

You acknowledge and agree that the Service and any necessary software used in connection with the Service ("Software") contain proprietary and confidential information that is protected by applicable intellectual property and other laws. [...] Except as expressly authorized by Yahoo! or advertisers, you agree not to modify, [...] distribute or create derivative works based on the Service or the Software, in whole or in part.

Yahoo! grants you a personal, non-transferable and non-exclusive right and license to use the object code of its Software on a single computer; provided that you do not (and do not allow any third party to) copy, modify, create a derivative work from, [...] or otherwise attempt to discover any source code [...] or otherwise transfer any right in the Software. You agree not to modify the Software in any manner or form, nor to use modified versions of the Software[...]. You agree not to access the Service by any means other than through the interface that is provided by Yahoo! for use in accessing the Service.
And yet Flickr provides a syndication feed too! (I suppose the "interface that is provided by Yahoo! for us" could get a get-out clause for the syndication feed...) (http://help.blogger.com/bin/answer.py?answer=697)

From:

The linked script allows a user who has a login on the system the CGI runs on to (over-)write any filename that the CGI can write to.

Stripping out script tags from HTML is doomed to failure unless you do a full SGML parse and reconstruct the message using only known-good elements and conservative quoting, since you cannot possibly hope to take account of the quirks everyone else's HTML parsers.

From:

Thanks for your help again.

The linked script allows a user who has a login on the system the CGI runs on to (over-)write any filename that the CGI can write to.

Good point, though not relevant as I'm not using the save-back-to-disk part of the script.

Stripping out script tags from HTML is doomed to failure unless you do a full SGML parse and reconstruct the message using only known-good elements and conservative quoting, since you cannot possibly hope to take account of the quirks everyone else's HTML parsers.

Does changing all angle brackets into HTML entities such as I have in my script count as conservative quoting in this instance?

From:

Yes, but if you're going to do that, I'm not sure why you want HTML input in the first place?

From:

I don't; I want plaintext. Only the plaintext is getting interpolated into the HTML in place of the webform for forwarding on. The end-user doesn't know that, but I can't risk them second-guessing it.

From:

Ah, right. I'm unclear at what point you're substituting into HTML, but whatever point that is is the point you should SGML quote it, and not before.

I would:

Convert at least < and & into entities;
Strip out control characters (0-8, 11-31, 127-159);
Convert anything outside ASCII range into numeric character references, avoiding the need to know what encoding the output uses

Obviously you need to know what the input encoding is in order to be able to correctly interpret any bytes outside the 0-127 range. DisOrder uses <form ... enctype="multipart/form-data" accept-charset=utf-8> to request that the input be UTF-8.

Once you have encoded every character with special meaning, there is no need to delete script tags, since there's no possibility of anything being interpreted as a tag any more.

From:

Great, thanks.

From:

Don't bother with Flash for anything that you can do any other way at all. You'll only have to do it all twice for the benefit of people without Flash (and keep the two versions synched).

From: