On Fri, Dec 17, 2010 at 09:47:00AM +0000, Marc Herbert wrote:
> This is more or less
> the type of problems I had in mind:
>
> http://hea-www.harvard.edu/~fine/Tech/cgi-safe.html
Wow, there is some atrocious code on that page (being shown as "what not
to do"). I have no doubt that code just like it is written every day,
however. We see it all the time in IRC and on this mailing list....
The single biggest problem demonstrated by that page is the tendency
of people to invoke a shell from some other language to do something
for them. The example they use (from perl) is:
open ("/bin/ls /data/cardfiles | grep $searchspec |");
Even if we fix all the shell mistakes (and this line trips three major red
flags for me just at the shell level!), there's still a fundamental flaw --
it's passing user input data to a command interpreter, namely /bin/sh
(which is hidden by the perl syntax, but which is invoked implicitly).
And there's absolutely no good reason to do so, either -- as the page
says, "Avoid starting external programs where possible." This should
be handled by iterating through the filenames within perl and filtering
out the ones that aren't wanted -- not by invoking three external programs.
That sidesteps not only the three huge mistakes in the shell code, but
the *entire shell*.
> The number of security recommendations on this page is impractical for
> any programmer but an expert one. This is just too complicated.
I would claim that writing a secure CGI program in any language requires
an extremely pedantic (possibly even paranoid) approach. Novices are
well advised to stay far away from it, without some experienced guidance.
Granted, the shell makes it easier (compared to most languages) to fall
into traps... but the traps are there in every language. CGI programs are
exposed to the nastiest, most malevolent input strings you can imagine,
plus all the ones you couldn't imagine -- but someone else certainly did.
All input must be thoroughly and aggressively sanitized.
