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."
Michael dropped the soap again. Be gentle.
I'm a little source code, robust and stout.
Here is my input, here is my out.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
You do not have any children, now do you? ;-)
The article is interesting, and they are right to point out the many dangers of relying on environment variables. Where I work (unidentified to protect the incompetent), programmers are not allowed access to the unix command line. Instead, all user exits are trapped, and programmers are forced to navigate through a homegrown menu system.
This menu system relies on an environment variable ${WHATCANIDO} to store a list of permissions available to that user. Of course, I changed my .profile to add my own extension to the permission list. I even nicely dated, initialed, and described my change. ;)
export WHATCANIDO=world_domination:$WHATCANIDO # 2000/10/31 tw Too easy
So now when I get frustrated with the absurdity of this arrangement, I just take echo the environment variable to remind myself why I'm right and they're wrong.
> echo $WHATCANIDO
world_domination: [deleted]
The last time I checked coders in corporations got promoted for churning out the largest number of apps with the largest number of features in the shortest amount of time. The people who promote them are legitimate users of the application so they don't think to try to break it and see what happens. The security break-ins occur years after the original coder is gone.
Besides - leaving some small holes in your code guarantees future work - which is hard to come by in this day and age.