Date: Mon, 10 Jul 2006 15:37:17 -0500 (CDT)
From: Meet Myself on the Internet <me@...eabstracta.net>
To: Gezim Hoxha <gezimetc@...w.ca>
Cc: "Geo." <geoincidents@....net>, bugtraq@...urityfocus.com
Subject: Re: Securing PHP or finding PHP alternatives (was: PHP security (or
 the lack thereof))

On Fri, 7 Jul 2006, Gezim Hoxha wrote:

> On Tue, 2006-27-06 at 07:41 -0400, Geo. wrote:
>>>> Is php secure by default when it's installed on a server?
>>>>
>>>
>>> This question does not really have any meaning. If you ask, if php
>>> _applications_ are secure by default, the answer is of course "it
>>> depends" (most php applications are broken. Just do a
>>> "grep -R eval ." and see for yourself)
>>>
>>> The php safe_mode is not really safe. magic_quotes_gpc is broken by
>>> design. Where does that leave us? Write secure code, validate all input
>>> or get hacked, as is the case with every other software/language.
>>
>> It's not a meaningless question, it's a quite valid way to look at web
>> server extensions. You make it sound oh so simple "write secure code" but
>> I've been a hacker since 1980 when I wrote a bbs program in assembler and
>> tried to secure it. Writing secure code is anything but simple. It takes a
>> really good programmer to write code that is secure by design because you
>> have to understand exactly how the language and in some cases the hardware
>> you use functions.
>>
>> A language for websites should never expect to have this level programmers,
>> heck it's a bunch of artsy web developers who are going to be using it so it
>> should take that into account and allow the machine administrator to at
>> least be locked down at the start so he has to enable the features and only
>> those features the web developers require. It's the only way to make a
>> powerful web language and still maintain some semblance of security.
>
> With all that's been said in this thread, and all that has been observed
> (i.e. a large number of PHP vulnerabilities--please don't try and defend
> this; the common thing that everyone agrees on is that PHP tries to
> cater to all users (not necessarily programmers, which can make it
> insecure), I'm going to ask two questions:
>
> 1.) If I have to write PHP, how do I write secure PHP? Give me a number
> of ensures that I can follow and check-mark each and live a happy
> life--for the most part.

Whichever input provided from outside of your "safe data", that is:

- Cookies
- Headers
- GET/POST data
- Anything else I might have forgotten (Be paranoid)

Should be taken and treated as insecure and as such handled with care. If 
your variable "id" is expected to be a number, you should make sure only 
numbers are assigned to that var (i.e $var + 0 == $var should do for 
checking if the variable contains numbers only). PHP makes no 
distinctions, the variables are permissive to the point of accepting 
pretty much anything you feed them (strings and numbers).

If you expect a string, you should make sure only the data you expect is 
fed from the client by limiting its scope, be it escaping a few symbols 
(like '`<>-, etc) which may lead to sql injections or sanitizing input to 
avoid xss vulnerabilities.


> 2.) From a security standpoint what is a better, open-source replacement 
> to PHP?

Any cgi/webapp that was written in any other language should avoid your 
concerns with PHP, but your question suffers from misunderstanding what 
comprises a "php security issue" and the issues themselves. The problems 
aren't caused by php itself, they're caused by programmers who aren't 
aware of how everything works at the underlying levels, that is the http 
protocol and its extensions, the webserver, how data is treated and 
transacted from server to client and vice versa. There's no replacement 
for php, because the php authors took the effort of making the language 
interpreter portable across several systems, as such, you're likely not 
see a competitor anytime soon, but you should look for how to write better 
code. One book I've read about 2-3 years ago, was "Hack proofing your 
network" which contained a chapter about web audit iirc, I recommend it as 
a starting point, you should also look for a paper called "how I hacked 
packetstorm" written by rfp (the same author of the web audit chapter on 
the book I recommended up there).

>
> Thanks, -Gezim
>
> P.S.: This is my first bugtraq message, so take it easy on me :)


Cheers,
/GG

Powered by blists - more mailing lists