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

And code reviews, code reviews, code reviews

[Brahmastra]

I believe code reviews with a large enough group of people to be extremely useful. Yeah, it takes time and you get some irritating comments from a few people about how there is a space between something or comma between something, but when multiple eyes look at it, someone always catches something you didn't. A few hours of extra pain on the side of programmers can prevent pain for millions in the form of blaster viruses, etc.

The more things change....

[billstewart]

One of the first lessons we learned in CS100 was to always validate the input, assuming that it might be bogus or actively malicious. I've been appalled over the last 25 years at the number of products, developers, and companies that don't understand that. Most of the internet security problems we've seen have been from inadequate handling of input data, typically the buffer overruns that are so easy to program in C if you're not paying attention.

The article's worth reading, and really does justify it's "Level: Intermediate" label. Unlike when I was learning to program, there are lots of sources of input beyond your deck of punch cards (:-), and the author does a good job of explaining many of them, such as evil things that environment variables and file descriptors can be used for.

Re:Windows & Belkin

[AuMatar]

There are no controls on Windows inputs. Any process can send any message to any other process. Talk about insecure.

You could probably majorly screw up a progoram by sending it random message numbers. It'd react as if you were sending random menu and other commands. Hmm, that sounds like a fun prank to play...

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.

Murphy's Law strikes again.

[Dr. Bent]

It is a widely accepted engineering maxim that systems should be designed so that it is difficult to use them improperly. This is why (for example) a 110 volt plug will not fit in a 220 volt outlet. Developers who are concerned about the quality of the software they make would do well to follow this rule, and not just for security reasons. You should verify input data as early and as rigorously as possible wherever you can. Take advantage of things like XML validation and text box constraints to make it hard for users to enter bad data. And always follow the Fail-Fast principle...if something goes wrong: Complain! Loudly!. Don't let the user continue working if something has gone wrong. It's better to crash than to produce an erronous result.

Just a little advice from a developer who's made enough mistakes to know better.

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

[borkus]

A big issue for many web programmers is failure to realize that forms and web interfaces that you provide the user aren't the only way to interact with your application. A lot of them pay attention to JavaScript validation and maxlength attributes rather than check the data on the server.

New developers working on applications open to the internet often aren't used to developing in an evironment where programmers that don't work for their employer can access their app. All it takes for one dishonet person who knows slightly more than you to hack your app.

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.

Re:Problem: Hacker Languages

[BattleTroll]

"But almost nothing else should be written in C/C++"

What world are you living in? Blaming poor technique on the tool used is moronic. There are ample examples of poorly written, poorly secured Java code the invalidate all of the premises in this rant. I've seen hard coded passwords baked into java source that were visible through a 'strings' call. Someone forgets to obfuscate his or her classes, and the entire structure of the program is available through a reverse compiler. Sure, the JVM protects one from buffer overruns and the like but don't for one minute think that programming in Java prevents stupid errors from exposing you to vulnerabilities.

Not to mention there are areas where java is not the silver-bullet you describe. If you need precise control over your memory allocation, java is not the tool to use. If your application requires precise timing, java is not the tool to use. Need to control over the placement of allocated memory? Writing your own transport layer? Need hooks into the kernel?

The prime directive still holds true - use the correct tool for the job at hand. Follow the lemmings of "this tool is the only one you need" at your peril.