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