Secure Programmer: Keep an Eye on Inputs

An anonymous reader writes "This article discusses various ways data gets into your program, emphasizing how to deal appropriately with them; you might not even know about them all! It first discusses how to design your program to limit the ways data can get into your program, and how your design influences what is an input. It then discusses various input channels and what to do about them, including environment variables, files, file descriptors, the command line, the graphical user interface (GUI), network data, and miscellaneous inputs."

Comments

Re:perl -T says it all

[Carnildo]

The Perl language has built-in "taint-checking" enabled via the -T command line switch which causes Perl to automatically keep track of all information that possibly came from a user input and not allow any of it to do anything harmful (basically end up on a command line or in a file name).

There are other harmful things that data can wind up doing that Perl can't check for. Things like being used as SQL queries, or the classic "pass the price as a CGI parameter" mistake. Taint checking is more useful as a reminder that you need to validate input than a way of keeping potentially bad input isolated.

Perl's taint checking

[Eryq]

Perl programmers interested in writing secure scripts should *definitely* know about the -T (taint checking flag).

From the FAQ:

As we've seen, one of the most frequent security problems in CGI scripts is inadvertently passing unchecked user variables to the shell. Perl provides a "taint" checking mechanism that prevents you from doing this. Any variable that is set using data from outside the program (including data from the environment, from standard input, and from the command line) is considered tainted and cannot be used to affect anything else outside your program. The taint can spread. If you use a tainted variable to set the value of another variable, the second variable also becomes tainted. Tainted variables cannot be used in eval(), system(), exec() or piped open() calls. If you try to do so, Perl exits with a warning message. Perl will also exit if you attempt to call an external program without explicitly setting the PATH environment variable.

Re:If you input ever displays as HTML

[mcrbids]

forms and web interfaces that you provide the user aren't the only way to interact with your application.

So true, so true. For example (in PHP)

<?
if ($login='Admin' && $pass='19ak129')
$secure=true;
if ($secure)
{ // do something very important.
}
?>

In many cases this script's security could be bypassed by adding "&secure=true" at the end of the URL!

I prefer to generate or define a set of values that are acceptable and check with in_array().

EG:

<?
$acceptable=array('a', 'b','na');
if (!in_array($acceptable, $_REQUEST[check]))
die ('Sorry. Input in field "check" is invalid');
?>

Or by using a regex. Assume that the input must be a number:

<?
$match="/[0-9]+/";
if (preg_replace($match, '', $_REQUEST[number]))
die ('You must put in a number');
if (strlen($_REQUEST[number]>5))
die ('Number you have entered is out of range');
?>

You can oftentimes functionalize these so that it's as simple as:

<?
if ($error=Valid_Integer($_REQUEST[number]))
die($error);
?>

Simple methods that can greatly enhance security!

Perl security article in SysAdmin magazine

[merlyn]

I wrote a similar article recently for SysAdmin magazine, although the focus is more about Perl.