Hi, On Sunday 14 August 2005 16:50, Zeev Suraski wrote: > >1. Remove register_globals completely > > > >2. Remove magic_quotes_* > > Given what I said above, I don't see any motivation to remove > register_globals or magic_quotes. I don't see how it buys us anything > other than pissed off users and hordes of (sometimes exploitable) bugs that > will result from sloppy audits. These changes alone would mean that a > great deal of the applications would have to be 100% audited before an > upgrade. Between us, developers welcoming forced labor due to upgrades is > wishful thinking. People never like to be forced to go over their or other > people's code regardless of the circumstances.
I don't agree here. First of all: I read many posts in different support forums by people who's application broke due the register_globals = Off change. We teached them to use super globals instead of register globals. It was hard to quote the same answer that often but it worked out - somehow. People now write code using super globals for external data and maybe even check them for bad data but they don't initialise their global variables proper. Running on a host with register_globals = On, like a mass hoster, this enables code-paths and vulnerabilities the original author didn't think of. Now what happens if we remove register_globals it won't hurt the ones doing what was suggested - using super globals. The applications that break can easily "fixed" by using extract() inside an auto_prepend file which might be easily provided in release notes, a PEAR Compatibility library and by different support forums. But it would fix problems existing since the programmer didn't think off it. (I myself had recently a problem with loosing one of my session variables which was hard to find. This only happend when the user opened a few pages in the right order since the application used a global variable with the same name as a session variable. Such things are hard to track if you work on large code basis and written for register_globals=off but it needs to run with the setting on) magic_quotes is even worse for portable applications. You always have to check wether it is on or off and in one case you need to process you input data. This is a wtf factor for someone starting with PHP - I can remember how I wondered when I got escaped data out of my database. Coming from other languages I was used to escape data so I did with PHP. Now, after quite some years of PHP in a daily basis it's a real pain. Reading different support forums there are quite often people asking where these escaping comes from and how to handle this - that's a real pain for the users. If it's removed it can easily replaced by the filter stuff or some auto_prepend-"magic". Both are things which can, after they were removed, easily simulated in user-space but won't hurt any new application and, as I wrote above, can simply by userland code. This would be hard for the support forums the first few months but with a good FAQ article giving solutions these can be solved without much too much trouble compared with the trouble they can create. The benefit with having this - well documented - in the userland is that it would (most of the time at least...) only be enabled for applications not written portable but new, portable, applications don't need to care about this. Now back to what you wrote, Zeev: In the part I quoted above you wrote that "applications would have to be 100% audited" I don't think so. You jut need to check wether it uses one off these settings and apply the proposed work-around. This should be doable by taking a look at the documentation or a short look on the code or even, without a look on the code, just check if it works (accepting input data and handling quotes right). If you really want to fix this it would takes longer- but you would need to fix it anyways if you want it to be portable and running under most setups. > If we are to do anything about register_globals, perhaps we can change the > name of the directive to something else (e.g. unprotected_globals), and of > course keep its default 0. Admins will have to make an informed decision > to turn it on again, and we can speak against it as strongly as we want in > an upgrade guide. I don't think renaming it would make anything better but just add a new wtf. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
