Bug #73920 [NEW]: Reform of file_uploads in php.ini

From: admin at yoorshop dot fr Operating system: centos 6.8 PHP version: Irrelevant Package: URL related Bug Type: Bug Bug description:Reform of file_uploads in php.ini Description: ------------ Hi, Even if we use CXS to protect websites, it is not sufficient sometimes, many hackers succeeded to take control over websites by injecting a pyramid of files which are not detected as exploit or virus, but rather these were efficient php scripts which we truly traveling in the site files until it got to sensitive datas. We saw that dozens of times this year, and it is true that some modules/templates with exploits had facilitated the job of the hacker... mail, sendmail are now forbidden on our servers, this is also an incredible spam expoit, and deprecated totally... file_uploads is a security disease on which PHP community has never made efforts to reform itselves... We suggest : existing file_uploads = OFF all the time adding a second file_uploads_sess by ex, which can override orignal file_uploads, and which would be ON by default of course : file_uploads_sess = ON Conditions are authentication, only those who are authenticated successfully could send a file (only these need to be able to do that, begining by the webmaster to create his products in his shops or a blogger post his articles + pictures) : - webmaster through admin website - a user forum or client of website also for support by example : he can send a screenshot - for contact form without authentication : we could introduce a secondary acceptable condition : captcha Thanks for attention, John Test script: --------------- Hi, Even if we use CXS to protect websites, it is not sufficient sometimes, many hackers succeeded to take control over websites by injecting a pyramid of files which are not detected as exploit or virus, but rather these were efficient php scripts which we truly traveling in the site files until it got to sensitive datas. We saw that dozens of times this year, and it is true that some modules/templates with exploits had facilitated the job of the hacker... mail, sendmail are now forbidden on our servers, this is also an incredible spam expoit, and deprecated totally... file_uploads is a security disease on which PHP community has never made efforts to reform itselves... We suggest : existing file_uploads = OFF all the time adding a second file_uploads_sess by ex, which can override orignal file_uploads, and which would be ON by default of course : file_uploads_sess = ON Conditions are authentication, only those who are authenticated successfully could send a file (only these need to be able to do that, begining by the webmaster to create his products in his shops or a blogger post his articles + pictures) : - webmaster through admin website - a user forum or client of website also for support by example : he can send a screenshot - for contact form without authentication : we could introduce a secondary acceptable condition : captcha Thanks for attention, John Expected result: ---------------- Hi, Even if we use CXS to protect websites, it is not sufficient sometimes, many hackers succeeded to take control over websites by injecting a pyramid of files which are not detected as exploit or virus, but rather these were efficient php scripts which we truly traveling in the site files until it got to sensitive datas. We saw that dozens of times this year, and it is true that some modules/templates with exploits had facilitated the job of the hacker... mail, sendmail are now forbidden on our servers, this is also an incredible spam expoit, and deprecated totally... file_uploads is a security disease on which PHP community has never made efforts to reform itselves... We suggest : existing file_uploads = OFF all the time adding a second file_uploads_sess by ex, which can override orignal file_uploads, and which would be ON by default of course : file_uploads_sess = ON Conditions are authentication, only those who are authenticated successfully could send a file (only these need to be able to do that, begining by the webmaster to create his products in his shops or a blogger post his articles + pictures) : - webmaster through admin website - a user forum or client of website also for support by example : he can send a screenshot - for contact form without authentication : we could introduce a secondary acceptable condition : captcha Thanks for attention, John Actual result: -------------- Hi, Even if we use CXS to protect websites, it is not sufficient sometimes, many hackers succeeded to take control over websites by injecting a pyramid of files which are not detected as exploit or virus, but rather these were efficient php scripts which we truly traveling in the site files until it got to sensitive datas. We saw that dozens of times this year, and it is true that some modules/templates with exploits had facilitated the job of the hacker... mail, sendmail are now forbidden on our servers, this is also an incredible spam expoit, and deprecated totally... file_uploads is a security disease on which PHP community has never made efforts to reform itselves... We suggest : existing file_uploads = OFF all the time adding a second file_uploads_sess by ex, which can override orignal file_uploads, and which would be ON by default of course : file_uploads_sess = ON Conditions are authentication, only those who are authenticated successfully could send a file (only these need to be able to do that, begining by the webmaster to create his products in his shops or a blogger post his articles + pictures) : - webmaster through admin website - a user forum or client of website also for support by example : he can send a screenshot - for contact form without authentication : we could introduce a secondary acceptable condition : captcha Thanks for attention, John -- Edit bug report at https://bugs.php.net/bug.php?id=73920&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=73920&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=73920&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=73920&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=73920&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=73920&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=73920&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=73920&r=needscript Try newer version: https://bugs.php.net/fix.php?id=73920&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=73920&r=support Expected behavior: https://bugs.php.net/fix.php?id=73920&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=73920&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=73920&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=73920&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=73920&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=73920&r=dst IIS Stability: https://bugs.php.net/fix.php?id=73920&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=73920&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=73920&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=73920&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=73920&r=mysqlcfg