[Klug-general] Web Scripting Languages

[MacGyveR]

On Sunday 07 Jan 2007 21:57, Karl Lattimer wrote:
> > 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 ;)
>
>
>
> _______________________________________________
> Kent mailing list
> Kent at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/kent

"PHP can be run as either a CGI application or as an integrated Web server 
module. Regardless of its mode of execution, the PHP interpreter has the 
potential to access virtually every part of the host -- the file system, 
network interfaces, IPC, etc. Consequently, it has the potential to do (or be 
forced to do) a lot of damage. "

http://www.developer.com/lang/article.php/918141

you can do much more than sql injection with php, arbitrary code execution is 
the buzz hack of the moment with php apps. an example of this is seen on 
popular os apps such as phpbb2 security issues.

"access to the shell via the apache user easily"

anyone who runs cgi scripts as the apache user is living in the past :-) you 
use a different more restrictive user (but saying that mod_php runs normaly 
runs as the apache user :-), 

this should be done in php too with su_php:

http://www.suphp.org/

otherwise all your php scripts will be equal on your server (normally running 
as the apache user)

43 percent of web app problems in 2006:

http://www.securityfocus.com/news/11430

php security boss leaves php saying that securing php is futile:

http://blog.php-security.org/archives/61-Retired-from-securityphp.net.html

I don't think php is a secure language, but it does have it's uses (i use it 
on my own site)

-- 
--------------------------------
http://www.thedumbterminal.co.uk