Re: [RFC] Script only include/require

From: Date: Tue, 24 Feb 2015 23:25:16 +0000
Subject: Re: [RFC] Script only include/require
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to internals+get-83715@lists.php.net to get a copy of this message
Hi! > As far as I know, PHP is the only language that has this type of malware. > (Script embedded images) PHP is the only one malware vendors claims > it as "PHP malware". This is the fact. Which type is that? Of course only malware in PHP can be presented as "PHP malware", but I don't understand why it is of any significance. > The reason is other languages are almost safe by default against script > inclusion attacks. Many languages just don't use patterns like PHP code does - I don't think I ever seen Python code doing imports based on variables - I'm not even sure it's possible in Python. PHP has more capabilities, but of course you need to use them in the right way. > This RFC makes PHP safe by default just like other languages + > move_uploaded_file() > protection. No, it does not - I've shown the example why. I'm sure there are more. > People do not have to be exparts of developing softwares. Managers will > choose illogical choice. We should not base our decision on the opinions of people we all understand are ignorant. > 1. Anti-virus detects "PHP malware" > 2. Managers surprises possible attack (Server takeover) > 3. Developers are forced to check their code, since current PHP has no > effective script inclusion attack prevention > > With this RFC, developers can explain this type of attacks cannot be done > by PHP's feature. i.e. Exploit servers via script embedded images, etc > cannot > be done. I don't think we need to introduce BC-breaking feature in PHP just because somebody has a manager that can't understand the basics of security. > Embedded PHP script uploads are prohibited by this RFC by default. Only certain very narrow cases of it. > > PHP became as secure as other languages with respect to script inclusions. You keep repeating that, but it's not the case, and PHP already is as secure as other languages - provided you do not use clearly broken code. Security of the language is a misnomer anyway - language can not be secure (unless it's a language that does nothing useful), only specific code can be. Code that allows user-controlled includes without adequate filtering is insecure, and pretending that we make it secure does not improve security, quite the contrary. > Users may shoot their own foot, this is not our issue. But that's exactly what is required for your change to be useful at all! -- Stas Malyshev smalyshev@gmail.com

« previous php.internals (#83715) next »