[Klug-general] Web Scripting Languages

Karl Lattimer karl at qdh.org.uk
Sun Jan 7 21:57:24 GMT 2007


> Admittedly I'm not a front end specialist.  (Back end stuff more my 
> thing.) So I'd be interested to hear other's experiences if it's not 
> taking the thread too far off topic.

Didn't see a good place to trim that last email, it was all very self
explanatory. ;)

What I like to do, is have all my back end stuff in a set of callable
functions and objects. Then inside the HTML I can do simple 

<?php if ($whatever) { ?>
Some crazy HTML
<? } ?>

and of course for data chunks

<? echo $variable; ?>

and for large chunks of code, things get a bit wierd, for instance say
you want a function to generate a list of site members + photo and
joined date or whatever. You don't want to repeat this every time in
your HTML in order to do it. So you shift it off to a insy binsy
module/template file. 

--- module ---
<?php while ($result) { ?>
<div><a href="<?php echo $variable; ?>">Some link</a></div
<? } ?>
--- module ---

--- page ---
<? import ("module.php"); ?>
--- page ---

This all looks gravy in dreamweaver

You could even import some security stuff at the top of your module in
order to make sure nothing untoward is going on. With few things to
check for, maybe a session login active before doing anything security
is easy when you're aware of the problem areas and there aren't many of
them.

IMHO abstraction is something you do in code yourself not rely on a
language for, the Tao of programming sez, "A place for everything and
everything in its place" which was taken from the good housekeeping
guide I believe. If you keep your files neat and tidy, well documented
and well named the problem of presentation/determination that is
inherent in web development just vanishes. ;)

This is why python is good ;)

K


PS. I do dispute the fact that mod_php is less secure than using CGI.
CGI has so many things wrong with it its just not funny. Using an
executable file which can be executed by a remote user you're opening up
a can of worms. You need to make sure you're on top of any security
concerns all the time, an example is the volume of regexp required to
handle things like ;s and |s is just too silly and most programmers
don't think about that, there probably are libraries which handle this
but that doesn't mean the problem goes away. With mod_php you have very
few flaws, yes there were a few buffer overflows and heap overflow
exploits a while ago, these were fixed as per the nature of FLOSS.
However, if you look at the sheer volume of past CGI scripting flaws and
BO and HO exploits for apache I think you'll find that the bucket has
many leaks anyway. The problem with CGI is that it opens up a serious
set of possible scripting flaws bad programmers writing bad code create,
but the problems with CGI are more severe than mod_php, for instance,
with php you're likely to expose part of the active database if you
overlook something, someone could inject some SQL and create a bad user
in the database or something else screwy. With CGI a programmer can
potentially accidentally create a massive gaping hole in a system, if
they're using suid scripts too then they've given away root. 

This and this reason is why cgi scripts are a favorite of crackers for
hire, fuzzing tools against cgi can pummel it into oblivion and allow
access to the shell via the apache user easily, with mod_php you've got
way more hacking to do to get a shell active.

I could demonstrate all of this, but to be honest I can't be bothered.
There are books on web hacking, if you want to know where the security
flaws are don't read the howtodo books, read the howtobreak books ;)





More information about the Kent mailing list