ack! noone here mentioned taintperl!
perl has a very groovy security feature: taint
you run "perl -T" or have uid != euid (eg: an suid perl script), and
it enables "taint mode". once on, it can't be turned off.
*all* perl cgi scripts should start with "#!/usr/bin/perl -T".
in taint mode, you can't read from files that are writable by others,
but this is just the simple bit.
any data read in from files, command line args, env args, locale data,
certain system calls, etc are "tainted" and can't be used for things
like passing to command lines or in any command that modifies files or
processes. yes, this means you have to explicitly set PATH, IFS, etc
before trying to run something.
taint follows the data around as its assigned to other variables,
etc. this is the extra cool part, and why it has to be done at the
language level.
to "untaint" something it has to pass through a regex pattern
match. you have to match the data (hopefully with a restrictive "only
characters from this set" regex) and then assign out of the (now
clean) $1, $2, etc variables.
see perlsec(1p) for taintperl and further perl security discussion.
another one is the "Safe" perl module. you can create "compartments"
which can disallow individual perl opcodes. (opcodes are also grouped
to make this actually possible to use ;)
each compartment also gets its own namespace and it *cannot* access
data outside the package it is evaluated in (from outside, you can
choose to share variables with the compartment). see Safe(3pm).
another unmentioned major feature of perl for web serving is
mod_perl. mod_perl allows you to do hook some perl code into just
about any part of apache, not just the content generation. this means
you can write authentication handlers, access control handlers,
generate server config settings, custom loggers, mime type handlers,
etc. (this is what i meant with my "what php will never do" comment
when i suggested i give a talk on mod_perl)
being able to write your own security policy in a nicely separated
authentication/authorization handler and then apply it through the
normal apache "require" statements (completely separated from you
actual web content) is very nice.
see http://perl.apache.org/, particularly the list of modules that
people have already written for mod_perl. some of them are *very*
nifty.
for actually producing content, i recommend HTML::Embperl. in fact,
i'm currently the libhtml-embperl-perl debian maintainer ;)
embperl lets you write normal html, except with perl code between
"[+ code +]" blocks (and others that do slightly different things).
GET or POST form data is passed through in the %fdat hash, sessions
(stored in a database, tracked with a session-id cookie) are
automatically created as soon as you write to %udat. html tables and
lists can be automatically generated from a single row template simply
by using the perl variable "$row" somewhere.
you can of course, break your page up and include pieces from other
files (eg: standard headers, footers).
some new stuff in embperl (still evolving a little, but very useable)
is HTML::EmbperlObject. with embperlobject, a "base" file is always
used as a starting point, and then you can include a magic '*' file,
which means "the actual page requested". it builds a search path
between the page requested and the base file used, which allows you to
override the included files by directory. so each page only includes
the actual content and nothing else. this allows you to (eg) change
the footer for one whole subtree and stuff like that.
see http://perl.apache.org/embperl/
(there's lots more, but this email is already way too long. if people
want me to espouse further on mod_perl/embperl, just ask - its what
i've been using at work for the last few months ;)
--
- Gus
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
