The principal he is trying to embrace is to not trust his input.
From a secure point of view any interacting entity can possibly be malicious, intently or otherwise. This means that you must be sure not to allow anyone the oppertunity of wreaking havoc. An example of how such a concept is acheived: creating strict grammars which are tokenized into real objects, with all out of band data filtered out first allows a virtually impenetrable barrier. Because the part which deals with stuff that can be exploited, say files, or external programs only gets predefined data which is calculated based on something else, and not the actual data which is passed, it is protected from harm.
An example is say, a file retreival utility. You make a directory tree of files, in a strict language - only alphaneumeircals, for example, with a predefined set of extensions.
In a web form you let the user specify the filename, as a path, and the extension from a pulldown menu, or something of the sort.
If the extension exists in a hash, goody. if not, we die.
Then you do something like
@path = grep { length $_ } map { tr/a-zA-Z0-9/cd; $_ } split("/",param("path"));. This way you only keep the legal parts of the path. anything like "/" or ".." is lost. Then you check the items one by one for existence, and if
$path[$#path] exists in it's perceeders with the extension from the hash, we return it.
What you've got to do is think how to get only what you know you'll be getting from potentially anything.
From my non-great experience writing secure CGI's the one thing i've learned is never ever ever make shortcuts, evaluated grammers, or anything that might be cause for complex input, without checking both before interpolation, and after. You want to check the most normalized, simplified level of input more maticulously than any, because that's the one where you may fail. It is also wise to use exception handling and fatals to browser, or whatnot, because this makes sure nothing gets executed after the error either.
This being said, I believe that if you maintain taint mode, which helps you remember how to do things properly, and you write cleanly or structurely, you can create sfe applications using eval, system, exec, or whatever. But it may be wiser to try and do without them.
The final debate I will try to bring up is the coding style.
Optimisation and structuring of code matters a lot. When trying to write secure code it is, in my opinion, very important to delay all optimisation to the very end, if at all, so that code auditing be made an easier task.
Optimisation also introduces, at times, hacks and glues which are faster or shorter to type but more complex and gray in terms of their functionality or behavior. Using things like variying contexes, short idiomatic quips instead of more methods/subroutines, and so forth make maintainablity throghout prepdocution harder, and contribute to the creation of implicit behaviour. If you are trying to be secure by making sure that you don't get a case to deal with aside from the ones you know how to (which is easier (=better) than being prepared for everything) then you should also make sure your code is not doing anything you don't know it is.
Layering is also a good aid when it comes to security. Making sure that things have to pass well defined barriers before they reach a certain level in your code adds to the clearity and robustness. Protecting namespaces, and making sure that code sections know everything about they're environment, and cannot access, via lexical scoping, hard references not being in their value set, or whatever, any data which they shouldn't. It's not only the user who can wreak havoc accidently. Bad code can also do that.
As a last note, security is mainly learning from errors and thus correcting perception and habits.
Kudos on the habit of thinking of this stuff, but perhaps the stuff should be thought over better. Using routines such as copying a sub from script to script makes you forget. Thinking over, for every script, what is not dangerous, and how to keep the subset of that which is needed for functionality is both a way to learn, and a way to limit more strictly.
-nuffin
zz zZ Z Z #!perl
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.