I wrote: > > If you are careful, you can defend against Scenario 1 with > register_globals > > on, but you need to understand all the stuff that PHP is > doing with the > > data, and that is a fairly complicated picture. Your > application can still > > work even if you don't understand that picture, and that is > how unsecure > > applications come about. With register_globals off, the > data movement > > picture is much simpler, and this is more of a "fail-safe" > mode: if you > > don't understand how the data moves around in PHP, your > application simply > > breaks ;)
And Rasmus added: > In your scenario setting your error_reporting level to E_ALL > will throw a > warning when you use an uninitialized $admin variable. That > will prompt > you to initialize $admin correctly and thus be fine with > register_globals > turned on. This is a good point, Rasmus. At the same time, it reenforces the point at the top: there is more one needs to know in order to write safe code with register_globals. Not much more, but it is more: one needs to know what the problem is, what E_ALL is, and how E_ALL helps address the problem. And clearly, there are a lot of people on this list who are not yet to that level. > I don't think it is quite as hard as everyone says to write > register_globals-safe code. I agree, completely do-able, if one just knows a little bit more. Kirk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
