10.7 Other Methods To Catch Programming Errors
10.7.3
163
The -T Switch — Enable Taint Checking
Strictly speaking, this is a mechanism to enhance program security rather than one which helps catch programming errors. As we have seen above, data passed into your programs from outside can pose significant threats if they are fed to backticks or functions like eval(). Although you may honour users of your programs to exercise self-discipline to specify valid data only, you should not carry this attitude. As demonstrated by the Internet spam mail problem, you can hardly rely on users to use your programs properly. A programmer who are conscious of security issues will instead regard all incoming data as if they are malicious, carry out all necessary validations and accept them only if they are valid. This defensive approach is the basic principle behind taint checking in Perl. Perl marks external data passed into the program as tainted. Before you feed such kind of data to potentially unsafe functions, you are required to manually untaint it. This forces you to think more carefully about whether every piece of input data is safe. In other words, you have to untaint a piece of data if both of the following conditions are satisfied:
?
it originates from outside of the program (and is thus tainted);
?
it, or its derivative, is going to be involved in a potentially unsafe operation. A potentially unsafe operation is one which may potentially change the state of the system.
Taint checking is more of a concern for CGI scripts and scripts which are executed setuid or setgid (see Appendix D for more information about setuid and setgid on Unix systems). In fact, for Perl scripts executed that has the setuid or setgid file permission bit set, taint mode is performed automatically and you do not have to enable it. Examples of tainted data include command-line arguments, data read from user input, files or received from network functions and environment variables. Results of system calls such as readdir() and form data received in CGI applications are also considered tainted. Examples of potentially unsafe operations are system(), backticks, eval(), opening a file with writable privilege. Filesystem functions such as unlink() and rename() and the low-level system calls that are not covered in this tutorial are also unsafe. You may find that all of them have one aspect in common — they may be potentially used to alter the state of the system. Note that print() itself is not considered a potentially unsafe operation. If you can open() the file with writable permission, then you are allowed to write into it even if data written into it are tainted. For example, in a program involving the open() function in write or append mode, if the filename derives from external data (such as input by user) then you are required to untaint it. The only way you may untaint a piece of tainted data is to extract from it by means of backtracking with regular expressions. For example, the following example allows you to get the directory listing as generated by the ls command of arbitrary directories inside the current directory, but not outside of it. 1 2 3 4 5 6 7
#!/usr/bin/perl -Tw use strict; my $path = $ARGV[0]; if (defined $path and $path =∼ m/ˆ(((\w|\.\w|\.\.[.\w])[.\w]*\/?)+)$/) { # $1 contains the path