Santosh: Personally what I think you did wrong, was to simply paste the header of that news article into your email. You simply said that PHP was hit by another security hole, that allowed crackers(sometimes incorrectly refered to as hackers), to gain access to any php service. I don't think you would have been attacked if you simply refered to some article said php was insecure, saying "This article says php is insecure". You seemed to be saying yourself that "PHP was insecure", and backing it up using that article. I think at this stage a bit of background in computer security is in order. There is no computer that is 100% secure. Even a computer that is buried 5 miles beneth a heavly guarded army base with no power or communicaton cables can be penetrated by the right person/people. In the same way nearly all software, including PHP has bugs. The difference with free/libre/open source software, is that any security critical bugs, are fixed within an extremely short timeframe, and so long as you update your machine regularly with any security related updates, you should be OK. This applies to all software of course, but the difference between PHP, and other other propriatory solutions is that security updates are released very soon after they are found. Ian: The department is right. PHP is a security risk. So is every other piece of software on your machine. What your department has to do is manage that risk. The default way of installing PHP will allow users on a shared server to execute commands under the web-servers UID. This can be, to a certain extent prevented using safe-mode, or better again, using something like suExec/suPHP (search google or apache docs). PHP is like any other server application. You need to decide what compromise between usability and security you want to make. You basicly want to make it as secure as possible, without sacrificing any essencial usability. As an example, disabling register_globals makes your script more secure, but you have to use $_GET['varname'] instead of $varname. That is IMO a usability sacrifice well worth making in the interest of security. You'll find plenty more security related articles on the net, as to how you can minimise the insecurity caused by PHP. On 8/25/05, Santosh Jambhlikar <santosh.jambhlikar@xxxxxxxxxxxxx> wrote: > As this is the php mailing list it is obvious that i should not write > against php. but people should know the truth. And it's a news (not by > me) that's why i wanted to send link to u peoples. > I am sorry if i did something wrong, i am new user in php mailing list. > > > Jasper Bryant-Greene wrote: > > > Santosh Jambhlikar wrote: > > > >> also > >> > >> PHP HIT BY ANOTHER CRITICAL FLAW > >> > >> A new security flaw in the PHP Web service protocol used by a large > >> number of Web applications could allow attackers to take control of > >> vulnerable servers. > >> http://www.computerworld.com/securitytopics/security/holes/story/0,10801,104124,00.html > > > > > > > > You are spreading FUD about PHP. Stop it. If you actually *read* the > > article carefully you will find that not only is this not a PHP bug, > > but a bug with two XMLRPC libraries written *for* PHP. Not PHP itself. > > This is completely irrelevant to the original topic, as I didn't see > > the OP asking for XMLRPC security advice. > > > > While you're at it, why not publish an article "PHP HIT BY ANOTHER > > CRITICAL FLAW" with the text "A new security flaw in my website, which > > is developed using PHP, surfaced today..." > > > > Jasper > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
