Re: php,perl,app svr, sql dbase preferences

[Danny Sauer <sauer@cloudmaster.com>]

On Wed, Sep 12, 2001 at 11:50:56AM -0500, Steven Pritchard wrote:
> Danny Sauer said:
> > Embedded Perl would also work, I suppose,
> > but I'm still partial to PHP for the web.  It's nice to just put plain HTML
> > in between ?> and <? instead of quoting and print()ing everything.
> 
> Err...  There are a bunch of different ways to do that in Perl.  I use
> Apache::ePerl on www.luci.org and www.silug.org...  See
> 
>     http://springfield.pm.org/meetings/apache.html
> 
> for how to set it up.

That's cool.  I do sometimes see things that php can't do but that perl would
do, or rarely, something that perl would make easier.  Remind me to add that
to the development server soon... :)

> > This all hinges upon language familiarity, though.  If you wanna learn some
> > new language, PHP is worthwhile.
> 
> I hate to start a language war, but PHP is a hideous piece of crap.  See
> 
>    http://www.securityfocus.com/templates/archive.pike?part=.1&list=1&mid=194488

Since the article is very much one-sided I feel compelled to present the
slightly-long, only-makes-sense-if-you-read-the-above-URL, section-by-section,
not-so-much-a-flame-as-an-alternate-viewpoint, Danny's response to that:

3 Global variables - 
	It's bad programming practice to trust variables that aren't set by your
	program, and the author neglects to mention PHP's variable scoping, wherin
	one must explicitly import global variables into a function's local scope.
	That point is made moot by initializing variables and/or by using functions
	for most functionality.

4 remote files - 
	OK, so the language makes it possible to transparently open URLs and
	local files with the same function.  Quite nice for the programmer,
	but again, the issue raised is not an issue in most cases, since included
	files should be hard coded at some level, not taken directly from the user.

5 file upload - 
	Yeah, this is a problem.  So disable file uploading, since web browsers
	aren't file uploading tools anyway.

6 include files - 
	Config files / libraries parsed out of context cause problems?  Only due
	to poor planning on the programmer's part, not due to a failing within PHP.

7 session files - 
	Well, don't use the existing session code.  I never have, and don't plan
	to, because I prefer to develop my own user-tracking system based on the
	needs of the current project.  But I suppose that lazy programmers again
	could encounter problems here if they blindly trust the user's input.

8 arrays/typing - 
	lazy/inconsistent/incompetent programmers again.

9 target functions - 
	hey, there's a list of functions that exist in many languages and which
	are frequently abused in those languages due to, drumroll here, lazy
	programmers or incometence that blindly trusts user input.  Programmers
	that think ahead don't have problems with these functions.

I see that in section 11 the author blames the language for making it easy
to write an insecure program.  How many times has someone written a program
in Perl that took user input and passed it to an open() or eval()?  Said
author attempts to blame the language because it's so easy to program in,
no-programmers are writing programs in it.  Huh.  I'll bet that a program
written by a non-programmer in ePerl, pike, or C is automagically more
secure because those languages do a lot to protect a programmer from lack
of knowledge.  PHP makes it easier to get burned in some places, but it also
saves quite a bit of time and makes some things harder to mess up.

The astute reader will notice that none of the PHP apps I've written are
listed in the "vulnurable apps" section.  That's not a coincidence, it's
a combination of my moderate level of competence and the fact that most
of the stuff I've written is not fit for public consumption. ;)  The point
remains, however, that even a moderately skilled programmer following any
reasonable set of programming guidelines will never experience these issues.
I personally like the language for it's intended use - quick development
of dynamic web content.  I'm hesitant to use harsh words to describe it,
though, as it's helped me out quite a few times.  I guess I disagree with
the article because I blame programmers (except in the case of Java, where
the language actually is a problem) for their programs.  The author presents
a valid point, but in my chunk of the world where I have final say on *all*
code placed on the web servers I care about, it's programers that write bad
code, not programming languages.

That said, I really like Perl, and would use it more if I could get modperl
and php to coexist a nicely (and if Perl's DBI stuff was a shade more
convenient to use).

--Danny, who ranted more than he originally intended to...
-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.