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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
