RE: Why should I use PHP after this?

Complication leads to many more security holes than simplification. The more complex a system is, the more likely it is to contain a security problem. In fact, it probably has more holes and problems than are ever discovered.

Any system, no matter how simple, CAN have security holes. It's the nature of the beast; when you have a system that anyone can use, there is the risk that one of those people will find a way to use it in unintended ways.

In this case, an attempt at simplification appears to have led to a security problem. I say appears not because I doubt there's a problem but because I don't pretend to know exactly what mistake was made here. I still much prefer simplification to complication.

- email Ozymandias

Comment on RE: Why should I use PHP after this?

Replies are listed 'Best First'.
RE (tilly) 2: Why should I use PHP after this? by tilly (Archbishop) on Sep 05, 2000 at 00:07 UTC
Actually most security holes, counting by number reported, are buffer overflows and the like. Most of which are caused by people reinventing invented wheels. But that is neither here nor there. Here is the actual problem. PHP by default willfully violates the good programming practice of not using symbolic references. Perl not only does not violate it by default, it allows you to stop accidental use of it with strict. In fact with PHP in the default configuration, anyone who wants can, by sending you a form with specifically named variables, set global variables in your program. In this case any PHP script that allows someone to upload a file can be tricked into using a local file like your password file. If it displays that, emails that, or whatever, you have handed out critical information. This is a serious security hole, and I am sure that a careful analysis of standard PHP programs will show other global variables that can be tweaked with "interesting" results. If you want you can go looking yourself. You just need to find scripts that think specific globals have been set in some sort of preprocessing and dream up a form that sets those variables to whatever you want. Now is this hole simplification? Yes, and no. The good kind of simplification is to divide a problem up into simple pieces and solve each one cleanly. This is not an example of that. The bad kind of simplification is to do whatever you can to make it simple to do things, with no thought of the potential consequences. This is an example of the latter. Most of the API that Microsoft provides in Office could serve as additional examples, and the periodic Melissa-class viruses are a consequence. (I am still waiting for the email virus that can hit people who read it, even if they have ActiveX turned off, through the Access mistake. That is kiddie scriptable. The neat buffer overflow in Outlook upon trying to parse the date is fortunately well out of your average kiddie's reach.)	[reply]

Replies are listed 'Best First'.

RE (tilly) 2: Why should I use PHP after this?
by tilly (Archbishop) on Sep 05, 2000 at 00:07 UTC

Here is the actual problem. PHP by default willfully violates the good programming practice of not using symbolic references. Perl not only does not violate it by default, it allows you to stop accidental use of it with strict.

In fact with PHP in the default configuration, anyone who wants can, by sending you a form with specifically named variables, set global variables in your program. In this case any PHP script that allows someone to upload a file can be tricked into using a local file like your password file. If it displays that, emails that, or whatever, you have handed out critical information.

This is a serious security hole, and I am sure that a careful analysis of standard PHP programs will show other global variables that can be tweaked with "interesting" results. If you want you can go looking yourself. You just need to find scripts that think specific globals have been set in some sort of preprocessing and dream up a form that sets those variables to whatever you want.

Now is this hole simplification? Yes, and no. The good kind of simplification is to divide a problem up into simple pieces and solve each one cleanly. This is not an example of that. The bad kind of simplification is to do whatever you can to make it simple to do things, with no thought of the potential consequences. This is an example of the latter. Most of the API that Microsoft provides in Office could serve as additional examples, and the periodic Melissa-class viruses are a consequence. (I am still waiting for the email virus that can hit people who read it, even if they have ActiveX turned off, through the Access mistake. That is kiddie scriptable. The neat buffer overflow in Outlook upon trying to parse the date is fortunately well out of your average kiddie's reach.)

[reply]