Introduction to the Apache Web Server - ApacheCon

19.5.1 CGI exploit example - trusting form input
One of the most common CGI exploit categories involved accepting data from HTML forms and trusting
it. Remember that the user cannot be trusted. Like your mother always told you, don’t put that in your
command, you don’t know where it’s been.
Consider the following scenario. You have a form on your web site, which allows users to send you feedback
email. Within your CGI code is something like the following:
open MAIL, "|/usr/bin/sendmail -s $FORM’subject’ $FORM’to’";
print MAIL $FORM’body’;
print MAIL "\n\n.\n\n";
close MAIL;
Looks pretty straightforward. Data comes in from the form fields subject, to, and body, and this gets
passed off to sendmail, which delivers the email. Email is composed to the address in to with a subject line
of subject and a body of body, all specified in the form.
There are two problems here.
The first is that a clever (or not-so-clever, really) spammer can use this form to send as many email messages
as they want, to whomever they want, by posting data to your CGI program. Since that email will come
from your server, you will appear to be responsible for that email.
The second problem is a little more subtle, and much more dangerous. It has to do with the awful way that
the code here is calling sendmail. Rather than using a module/library to send the email, it is calling the
system executable, and passing arguments to it. This is universally a bad idea, because it allows a clever
person to circumvent your command line and insert their own.
Consider, for example, if I enter into the form field to the value:
bob@foo.com ; rm -rf /
The first part of this is an email address. Great. But then I have the character ;, which terminates the
command and starts a new one. At a regular command line, the ; character allows you to type multiple
commands in the same line. Since your code is calling the command line, the same rules apply. So putting
this in the form field will cause the sendmail command to be abandoned, and my other command to be
executed, recursing through the entire file system deleting any file that I happen to have access to.
Fortunately for the hackers, there are several rather popular (read: widely installed) CGI programs that do
exactly that, and so all that they need to do is write scripts that attempt to put these sorts of arguments
into web forms and see if they can do anything.
19.5.2 CGI exploit example - hidden form fields
Hidden form fields are not hidden. This is another example of cosmetic security.
* Hidden form fields are not hidden.
121