Re: Security Issues

> I tend to agree with the advisory, in the sense that register_globals=on > encourages insecure code, and it would in fact help to disable it by > default. It's true that some (many) people don't understand that they > shouldn't 'trust' any data coming from POST or cookies anymore than they > should trust GET (well, in practice - slightly more, as it takes slightly > more advanced users to work around POST or cookies, than it does to add GET > variables to the URL). However, *lots* of pieces of code, probably even > most of them, are vulnerable to logic bugs because of register_globals set > to on, bugs that would have otherwise not exist. Bugs which occur due to > misunderstanding the 'reliability' of the form data sources are (much) more > rare, and usually, if not always, involve basic misunderstanding of the Web > environment. Security issues that are a result of register_globals=on > often occur even when the user is knowledgeable, and tries to avoid > security bugs. The WTF factor there is pretty high. But you don't acknowledge here that turning on E_NOTICE by default would effectively eliminate this coding mistake. > >The change I would rather see in php.ini would be to have the default > >error_level be set to E_ALL because then the above script would generate a > >warning complaining about the fact that $ok was not initialized. Since > >PHP can determine when variables are not initialized the case for > >turning register_globals off in this example is rather weak. > > PHP does not require or even encourage initialization of variables - > setting $ok to 1, and then checking it with empty() is considered 'clean' > code, but it'd be equally insecure. Huh? Please show a code example here. > As I said, it's easy, but it is considerably less easy than it is to add > GET variables. Let alone the fact that we're also dealing with SERVER and > ENV vars, which cannot be injected at all. How about people who check > server variables, such as HTTPS, using isset()? register_globals *is* evil. We are talking about default settings here. You cannot spoof this script using the current default: <? echo $REMOTE_ADDR ?> You can stick all the ?REMOTE_ADDR=foo you want in the URL and the server var will always overwrite it in the default config due to the default variables_order setting. > >And the case for leaving register_globals on is that it is a whole lot > >easier for people to figure out how to get started with PHP when the data > >is just there and you don't have to do any strange array tricks to get at > >your data. > > I don't think that this arguments holds much water, as register_globals is > the mother of many many security bugs, found in the most popular PHP apps > out there. We need to find a way to access form variables easily, but > without encouraging insecure coding, the way we do now. I disagree. Please show examples of this mother of all security bugs here. Examples of this not caught by E_NOTICE are difficult to come up with. -Rasmus