> 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
--
PHP Development 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]
