Slashdot Mirror

← Back to Stories (view on slashdot.org)

Secure Programmer: Keep an Eye on Inputs

Posted by michael on from the talk-to-the-hand dept.

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

1 of 157 comments (clear)

  1. environment variables by MellowTigger · · Score: 3, Funny

    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]