[PLUG] PHP verses JSP and servlets...

Ronald Chmara ron at Opus1.COM
Tue Jan 31 23:30:27 PST 2006

On Jan 31, 2006, at 7:56 PM, Charles Sliger wrote:
> I've also heard the "PHP is insecure" statement.
> Could someone give a short explanation as to where this comes from and 
> how
> "secure" PHP can be implemented?

Short? Aw geez....

Okay, here's the shortest summary I can come up with:
1. User submitted data is insecure by nature.
2. PHP makes it really easy to do things with user submitted data.
3. PHP also runs (typically) in the UID of the web server, thus, if you 
have 50 users on one server, they all have the *exact* *same* *perms*.

Longer? Well, that's where the meat is. Let's look at perl tainting, 
variable types and scoping, and secure programming practices, and then 

First up at bat: Tainting.
In PHP, by default, a script can use:
<? if ($foo = "yes") { bar();} ?>

Perl, OTOH, is kind of protective, and will throw a warning depending 
on whether or not $foo comes from user-supplied data, or a server 
script. PHP often doesn't care. Of course, a savvy programmer will 
actually *check* where data is coming from, and *validate* the data 
used. Using register_globals can help a bit, as can making sure that 
all server variables are initialized (ahead of time) which are not 

Next up: Variable types.
In client->server web programming, there is *no* *such* *thing* as a 
user-supplied int. Or a float. Anybody who tries to sell you a package 
based on such things is either deluded, or doesn't understand HTTP. All 
web text comes in as *strings*. Period. Programmers can *cast* that 
string data one way or another, but people used to concepts such as a 
float not being assigned a string value may be really alarmed when 
their assumed "int" or "float" turns out to be a string, which can make 
SQL injection quite easy.

Another swing at the issue: Variable scoping.
PHP, by default, is big on global vars. Very handy in some cases, very 
scary in others. People used to protected variables should *really* 
read the docs first. Rather than a model of "protected unless global", 
PHP often went with "global unless protected". (I once saw 11K users 
shut out because of this... not pretty).

And now, Secure programming practices.
This is a pet peeve of mine. Take variable "$foo=1". This can 
eventually make the var true/bool, a string, an int, a float, etc. If 
you are passing it though python, PHP, C, java, and whatever-else in 
the chain, each part of the chain needs to make sure that the data is 
within expected values, and that the value will not compromise the next 
part of the chain. Let's take a recent MySQL exploit, where a long 
string, passed by PHP, can create a string-format exploit with mysql.  
A programmer can limit the mysql_connect() (and subsequent arguments) 
to less than 1K (or even 256 bytes). Newbie programmers who don't 
expect attacks, and thus do not sanitize every variable used for a) 
size, b) casted data type, c) removing special (escape) characters, 
etc., get caught.

Finally: Perms.
PHP often runs as the apache (etc) user. If each user has an apache 
instance, for their *own* UID, this is not a problem. However, hosting 
sites often want to keep CPU load down, and thus, there is "one" PHP 
(aka web) user. This is where PHP's "safe mode" (which most PHP devs 
hate) comes in. "safe mode" is functionally about having ten trusted 
programmers on a home server. It doesn't work for 3K users on a box... 
they still have a sandbox to break out of, unless they each have their 
own webserver instance.

So, in conclusion, you asked how can a:
> "secure" PHP can be implemented

How can a secure C program be implemented on the server? You cannot 
make C secure anymore than PHP. What you *can* do is check if every C, 
or PHP program, is good. Lacking that, chroot each PHP user and 
webserver into their own box. This adds to CPU costs.

Ronin Professional Consulting LLC
4245 NE Alberta Ct.
Portland, OR 97218

More information about the PLUG mailing list