Web Conference 2004 Writing Perl/CGI Scripts for ITS/ASET Web services Security

CGI programming and security go hand-in-hand. Usually not the same hand and too often not yours. But there are a few things you should consider to make your programming efforts more secure.

• Security is the WHOLE PICTURE, not just a certificate on a server. Don't be lulled to complacency at the sign of a "secure server." Security includes protecting all of the vectors by which data and systems can be attacked and compromised.

  • Encryption protects data. SSL protects data in transit between computers over the Internet. Other forms protect data when they reside in databases or in files.

  • Firewalls protect computer systems. They attempt to keep the "bad guys" out, but fail to protect from internal attacks. They do this by limiting which applications (eg, Web, Email, Net-News, DNS, etc) are exposed for external access, but usually do little to protect the exposed applications. Firewalls may be useful for both servers and personal computers.

  • Permissions, ACLs and access control protect data from other people and programs while on a system.

  • Programs that are accessible by others may be broken into if the code has bugs or programming flaws. After all other considerations are met, the hardest part of securing an application is simply maintaining good bug-free code.

• The only totally safe computer is one unplugged from the network, turned off, stored in 10 feet thick concrete and buried at the bottom of the ocean...ok, so there are tradeoffs with security and functionality.

• Least Privilege

  • Only give write access to files that need it and then only to the people and programs that need it
  • Avoid giving write permission to folders whose files you don't mind loosing

• The Web server has one identity - controlled by the code written by anyone with write access to CGI enabled folders, and triggered and possibly exploitable by anyone in the world anonymously. In the case of the test script server, this is the identity of wwwservr on the server and test.scripts.psu.edu when accessing PASS (DCE/DFS). Be warned of others using the script server.

• Check your data at the door. When using user supplied data, including CGI parameters, Cookies, the Referer URL and the like, check it before using it in places where it can cause problems. Experts at system intrusion can send large amounts of data or invalid values in the least expected places.

  • Be VERY careful in calling other programs, what they are, and what arguments get passed on the command line. Be wary of UNIX shell command insertion.

  • Be wary of SQL command insertion.

  • Be careful of invocations of the open() function, as it can call other programs.

  • Use the size and maxlength attributes of the <input> HTML tag, but don't trust they will always work. The person or program talking to your Web server / CGI program may not always be a browser.

• If you can't build a brick house, tie your shoelaces... Learn about good security and programming practices, be vigilent and security minded and you will outrun most others so you won't be the bear's lunch.

Practical security

• Use the -w and -T switches. When you add "-w" to the end of the she-bang line, "#!/usr/local/bin/perl -w", you enable warnings, which are printed to STDERR. This can be helpful in finding bugs in your program. Since most security vulnerabilities are simply bugs in programs, this is a good start. However, you may need to use the backticks trick of the last page to see the warnings.

  The -T switch enables taint checking. It will give you warnings if you use data from the user without checking it first in functions such as system() and open(). Like -w, it may help you find potential problems, however it doesn't actually fix them.

• Well designed and written code means less buggy code. Less buggy code means more secure code.

  Clearly indented program code, with good choices of variable and function names, a healthy balance of comments, brievity of code where-ever possible and a healthy comprehension of the language and programming environment (Apache + CGI, etc) all lead to better code.

• This lesson is just the introduction. Please read more if you are interested in writing robust, secure and scalable applications.

If you have any questions, feel free to ask me - mailto:jcd@psu.edu

Content by: Jeff D'Angelo <jcd@psu.edu> © 2004

Last update on: Thursday, 17-Jun-2004 15:29:27 EDT