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:The more things change....

[agslashdot]

While I agree with you from a theoretical standpoint, I'm sure you are aware why things like this get overlooked in day-to-day corporate IT programming tasks.
eg. Manager says, write a UI that accepts username & account, and then spits out user transactions . During design phase, you invariably make the code hack-able so its easy to test. ie. I could put in "*" for account and it would spit out transactions of ALL users, regardless of the username. This is a useful backdoor, especially in development time when your UI has to interact with somebody else's data repository in some compplicated fashion.
Ofcourse, its a given that the input validation logic must be modified and backdoor must be taken out when the UI is actually deployed. But corporate practices being what they are, someone else takes ownership of the code at that stage, and either doesn't understand the "star-feature" ( *) , or thinks its cool to have this in case of emergency debugging, so leaves it there. Soon, this stupid program that should have been running standalone on someone's box, gets a facelift and is shoved on the internet. Some cracker comes along and puts in a star for account & gets all the transactions, & pretty soon, register.co.uk gets wind of this and reports it on front page. by then, original programmer has moved on to some other task, requiring a new back-door :)

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...

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.

Re:Murphy's Law strikes again.

[Rich0]

Keep in mind that the 110 and 220 plugs are designed to defeat accidental mixups. Computer input validation is generally designed to do the same. Hardening software against an attack is more analagous to giving your engineer the task of designing a plug and outlet such that it is physically impossible to plug anything but that one particular plug into the outlet, with the understanding that somebody with a good knowledge of engineering will try to defeat the design.

Software is required to do a lot more than any physical security measure in existance. Your webserver could come under attack by any electronic measures that you could conceive of by a host of trained software engineers in another country. Chances are that the most a bank vault is designed to handle is a dozen guys with small arms, rudimentary safe-cracking gear, and some small explosives. If the US Army showed up with an M1 tank and 1000 tons of C4, the safe wouldn't last long. However, such a large-scale intrusion is unlikely to escape the watch of the police for long. On the other hand, a remote attack against a webserver can run for months without much being done to the attackers if they're in a rogue nation.

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.

This was well documented in the 1970's

[pcause]

The Kernighan & Plauger book "Elements of Programming Style" dated 1979 talked extensively about the need to validate all inputs to subroutines and from the user. This is *not* new, it is just that few programmers have the discipline to follow the rules.

The issue is making *no* assumptions about anything. The programmer *thinks* the file will be written be another piece of code that a team member is writing. But that program has a bug. or three years from now, other programs are creating the file and don't know abut some verbal discussion about field data. It takes great dligence and paranoia and management that allows you the time in the schedule to do this.

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.