Re: [PHP-DEV] Security Issues (isset stuff)

2001-07-30 Thread Phil Driscoll
On Sunday 29 July 2001 19:13, [EMAIL PROTECTED] wrote: ...stuff pointing out how you'd get no warning messages when the evil guy sets the variables from outside. You missed my point, which is the good guy would get the warning messages when he tested the code himself without sending in the

Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras
UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: - My mind is pretty firm about implementing shortcuts for $HTTP_*_VARS. People are going to rebel big time if we remove their global variables by default, and make them use these exceptionally long alternatives instead. Most people I

Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras
UNSUBSCRIBE ME PLEASE!! Andi Gutmans schrieb: Hey, I thought of an idea yesterday which could make everyone happy. In the default php.ini we set the register_globals to a new value "unset". If PHP runs with this INI value it will display a page telling you that you need to define the

Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras
UNSUBSCRIBE ME PLEASE!! Ron Chmara schrieb: On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote: > At 06:01 28/07/2001, Phil Driscoll wrote: >> I and no doubt thousands of others will turn >> register_globals on because it gives much more readable code, >> much less >> typing

Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras
UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 16:28 28/07/2001, Ron Chmara wrote: >On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote: >>At 06:01 28/07/2001, Phil Driscoll wrote: >>> I and no doubt thousands of others will turn >>>register_globals on because it gives much

Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras
UNSUBSCRIBE ME PLEASE!! Phil Driscoll schrieb: On Saturday 28 July 2001 20:52, Zeev Suraski wrote: a rebuf to each of my arguments :) Rather than prolong the agony, my point is that in all the cases where a malicious user has the chance to inject a dodgy variable, the code must

Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras
UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 01:04 29/07/2001, Phil Driscoll wrote: >On Saturday 28 July 2001 20:52, Zeev Suraski wrote: > >a rebuf to each of my arguments :) > >Rather than prolong the agony, my point is that in all the cases where a >malicious user has the

Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras
UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 10:27 29/07/2001, Phil Driscoll wrote: >On Sunday 29 July 2001 17:35, Zeev Suraski wrote: > > *sigh* :) As I said numerous times, PHP gives you standard clean ways to > > test your variables without generating E_NOTICE's, namely,

Re: [PHP-DEV] Security Issues

2001-07-30 Thread Ramsi Sras
UNSUBSCRIBE ME PLEASE!! Phil Driscoll schrieb: On Sunday 29 July 2001 17:35, Zeev Suraski wrote: > *sigh* :) As I said numerous times, PHP gives you standard clean ways to > test your variables without generating E_NOTICE's, namely, isset() (very > popular) and empty() (less popular,

Re: [PHP-DEV] Security Issues - a bit of my experience

2001-07-30 Thread Ramsi Sras
UNSUBSCRIBE ME PLEASE!! Stephen van Egmond schrieb: Rasmus Lerdorf ([EMAIL PROTECTED]) wrote: > Think about whether in each of these cases it would have happened if the > developers of the app had developed with E_NOTICE on. In a high number of > these cases it probably wouldn't. And

Re: [PHP-DEV] Security Issues - a bit of my experience

2001-07-30 Thread Ramsi Sras
UNSUBSCRIBE ME PLEASE!! Stephen van Egmond schrieb: Zeev Suraski ([EMAIL PROTECTED]) wrote: > - register_globals=on leads to insecure code, which was demonstrated time > and time again in the past. > - Once it's off, we're going to provide methods of accessing variables > which are

Re: [PHP-DEV] Security Issues - a bit of my experience

2001-07-30 Thread Ramsi Sras
UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 21:34 29/07/2001, Stephen van Egmond wrote: >Zeev Suraski

Re: [PHP-DEV] Security Issues - a bit of my experience

2001-07-30 Thread Phil Driscoll
On Sunday 29 July 2001 19:42, Stephen van Egmond wrote: will produce warnings if $x is not set. If you don't want the warnings, you have to replace it with: if (isset($x) $x) { } if it's set and it's true...? ugh. One is then tempted to look for replacement

Re: [PHP-DEV] Security Issues - a bit of my experience

2001-07-30 Thread Zeev Suraski
At 01:22 30/07/2001, Phil Driscoll wrote: I agree - to my mind empty is broken in this respect and also in the respect that it returns true for a string containing '0'. Consequently I (and I assume everyone else, unless I'm missing some occasion that this behaviour is useful) can never use empty

Re: [PHP-DEV] Security Issues

2001-07-30 Thread teo
Hi Zeev! On Sun, 29 Jul 2001, Zeev Suraski wrote: Generally I agree, except I don't think we should go as far as changing the theme of PHP. Putting form variables into a different space would be the simplest and equally secure way to do the trick. yes, but a Request class can be enriched

Re: [PHP-DEV] Security Issues

2001-07-30 Thread Cynic
At 19:01 7/27/2001, Rasmus Lerdorf wrote the following: -- That's also not true. Is using $foo all that better than $_GET[foo]? For a neophyte user - most definitely. Rasmus, I disagree. As someone who's first programming language

Re: [PHP-DEV] Security Issues

2001-07-30 Thread Anil Madhavapeddy
Cynic wrote: Of course it is. $foo is conceptually simpler than $_GET[foo]. I don't see how you can say it isn't. $foo is conceptually a few keystrokes. That's all simplicity I can see. I think that's the whole point ... 1) $foo 2) $_GET[foo] One looks like PHP, the other looks like

Re: [PHP-DEV] Security Issues

2001-07-30 Thread Cynic
At 12:06 7/30/2001, Anil Madhavapeddy wrote the following: -- Cynic wrote: Of course it is. $foo is conceptually simpler than $_GET[foo]. I don't see how you can say it isn't. $foo is conceptually a few keystrokes. That's all

Re: [PHP-DEV] Security Issues (isset stuff)

2001-07-30 Thread teo
Hi Phil! On Mon, 30 Jul 2001, Phil Driscoll wrote: On Sunday 29 July 2001 19:13, [EMAIL PROTECTED] wrote: ...stuff pointing out how you'd get no warning messages when the evil guy sets the variables from outside. You missed my point, which is the good guy would get the warning messages

Re: [PHP-DEV] Security Issues (isset stuff)

2001-07-30 Thread Phil Driscoll
On Monday 30 July 2001 11:13, [EMAIL PROTECTED] wrote: Hi Phil! Yes Phil, but does your codes rely on warnings messages alone? No - my code relies on exceedingly thorough and paranoid validation of input, carefully constructed program flow, painstaking testing at all stages and no doubt

Re: [PHP-DEV] Security Issues (isset stuff)

2001-07-30 Thread Phil Driscoll
On Monday 30 July 2001 11:52, Phil Driscoll wrote: Some people agree with me, others disgree. As long as you have conrol of your php.ini file, it isn't a problem :) - although it will (indeed already does!) tend to discourage me, and probably others, from releasing any of my code for public

Re: [PHP-DEV] Security Issues

2001-07-30 Thread Cynic
At 13:44 7/28/2001, Zeev Suraski wrote the following: -- At 05:08 27/07/2001, [EMAIL PROTECTED] wrote: Addressed to: Rasmus Lerdorf [EMAIL PROTECTED] [EMAIL PROTECTED] Or you can simply stop these people from using PHP

Re: [PHP-DEV] Security Issues - a bit of my experience

2001-07-30 Thread Stephen van Egmond
Zeev Suraski ([EMAIL PROTECTED]) wrote: I don't think we can change the behavior of empty() at this stage... isempty()? -- 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

Re: [PHP-DEV] Security Issues - a bit of my experience

2001-07-30 Thread Jeffrey A . Stuart
AMEN! I PERSONALLY DO NOT consider it a PIA to have to access the variables via $HTTP_POST... What I USUALLY do is something like this: $fldform_var1 = $HTTP_POST_VARS[form_var1]; etc. This way, I'm GUARENETEED that I got the variable FROM the location that I was expecting. Then, I refer

Re: [PHP-DEV] Security Issues - a bit of my experience

2001-07-30 Thread Sterling Hughes
On Mon, 30 Jul 2001, Ramsi Sras wrote: Hey, idiot. you can just send a message to [EMAIL PROTECTED], stop spamming my mailbox, or else you'll be subscribed to alot more mailing lists than you ever wanted. -Sterling UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME

Re: [PHP-DEV] Security Issues

2001-07-29 Thread Zeev Suraski
At 16:28 28/07/2001, Ron Chmara wrote: On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote: At 06:01 28/07/2001, Phil Driscoll wrote: I and no doubt thousands of others will turn register_globals on because it gives much more readable code, much less typing and does not IMHO add one

Re: [PHP-DEV] Security Issues

2001-07-29 Thread Phil Driscoll
On Saturday 28 July 2001 20:52, Zeev Suraski wrote: a rebuf to each of my arguments :) Rather than prolong the agony, my point is that in all the cases where a malicious user has the chance to inject a dodgy variable, the code must normally have a logic path which allows the code to pass

Re: [PHP-DEV] Security Issues

2001-07-29 Thread Zeev Suraski
At 01:04 29/07/2001, Phil Driscoll wrote: On Saturday 28 July 2001 20:52, Zeev Suraski wrote: a rebuf to each of my arguments :) Rather than prolong the agony, my point is that in all the cases where a malicious user has the chance to inject a dodgy variable, the code must normally have a logic

Re: [PHP-DEV] Security Issues

2001-07-29 Thread Phil Driscoll
On Sunday 29 July 2001 17:35, Zeev Suraski wrote: *sigh* :) As I said numerous times, PHP gives you standard clean ways to test your variables without generating E_NOTICE's, namely, isset() (very popular) and empty() (less popular, but available all the same). There's a good, fairly darned

Re: [PHP-DEV] Security Issues

2001-07-29 Thread Zeev Suraski
At 10:27 29/07/2001, Phil Driscoll wrote: On Sunday 29 July 2001 17:35, Zeev Suraski wrote: *sigh* :) As I said numerous times, PHP gives you standard clean ways to test your variables without generating E_NOTICE's, namely, isset() (very popular) and empty() (less popular, but available

Re: [PHP-DEV] Security Issues - a bit of my experience

2001-07-29 Thread Stephen van Egmond
Rasmus Lerdorf ([EMAIL PROTECTED]) wrote: Think about whether in each of these cases it would have happened if the developers of the app had developed with E_NOTICE on. In a high number of these cases it probably wouldn't. And if this number is close to 100%, then it would point to the fact

Re: [PHP-DEV] Security Issues (isset stuff)

2001-07-29 Thread teo
Hi Phil! On Sat, 28 Jul 2001, Phil Driscoll wrote: That's not going to find half, or a quarter, or whatever of the problems, since PHP has tools to cleanly handle undefined variables - namely isset() and empty(). They, or at least isset(), are quite popular. I always use something

Re: [PHP-DEV] Security Issues

2001-07-29 Thread teo
Hi Zeev! On Thu, 26 Jul 2001, Zeev Suraski wrote: At 02:18 26/07/2001, Ron Chmara wrote: If most of the PHP apps out there are or were vulnerable to register_globals=on attacks, we can't (shouldn't) blame the whole world, but fix the language instead. I'd suggest fixing the code

Re: [PHP-DEV] Security Issues (backward fix)

2001-07-29 Thread teo
Hi Ron! On Sat, 28 Jul 2001, Ron Chmara wrote: On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote: At 06:01 28/07/2001, Phil Driscoll wrote: I and no doubt thousands of others will turn register_globals on because it gives much more readable code, much less typing and does

Re: [PHP-DEV] Security Issues - a bit of my experience

2001-07-29 Thread Zeev Suraski
What you ignored completely are three facts: - register_globals=on leads to insecure code, which was demonstrated time and time again in the past. - Once it's off, we're going to provide methods of accessing variables which are just as easy, and quite easier in case you access them from

Re: [PHP-DEV] Security Issues

2001-07-29 Thread Zeev Suraski
Generally I agree, except I don't think we should go as far as changing the theme of PHP. Putting form variables into a different space would be the simplest and equally secure way to do the trick. At 08:32 26/07/2001, [EMAIL PROTECTED] wrote: Hi Zeev! On Thu, 26 Jul 2001, Zeev Suraski wrote:

Re: [PHP-DEV] Security Issues - a bit of my experience

2001-07-29 Thread Stephen van Egmond
Zeev Suraski ([EMAIL PROTECTED]) wrote: - register_globals=on leads to insecure code, which was demonstrated time and time again in the past. - Once it's off, we're going to provide methods of accessing variables which are just as easy, and quite easier in case you access them from

Re: [PHP-DEV] Security Issues - a bit of my experience

2001-07-29 Thread Rasmus Lerdorf
I was trying to step back a bit and identify some of the patterns in the attacks identified in the paper. One extremely popular pattern was spoofing variables by overwriting them: GET variables overwriting POST, usually, and I suggested that some SAPI stunt be pulled to catch that. That's

Re: [PHP-DEV] Security Issues - a bit of my experience

2001-07-29 Thread Zeev Suraski
At 21:34 29/07/2001, Stephen van Egmond wrote: Zeev Suraski ([EMAIL PROTECTED]) wrote: - register_globals=on leads to insecure code, which was demonstrated time and time again in the past. - Once it's off, we're going to provide methods of accessing variables which are just as easy, and

Re: [PHP-DEV] Security Issues

2001-07-28 Thread Zeev Suraski
I wrote a thorough response while being disconnected, but it's kind of pointless to send it considering the face to face discussion we had today. The only thing I'd like say here is that in my opinion, the fact form variables are defined as globals (as opposed to being defined just as

RE: [PHP-DEV] Security Issues

2001-07-28 Thread Zeev Suraski
At 12:36 27/07/2001, Brian Tanner wrote: Differently - sometimes Dangerously - Never I think that this means that this is quite serious, and mind-bogglingly common security flaw. When your app behaves differently, there's a one out of two, or one out of five, or one out of ten chance that

RE: [PHP-DEV] Security Issues

2001-07-28 Thread Zeev Suraski
Yes, a $_FORM variable container is also on my TODO list for the new track_vars implementation... At 14:00 27/07/2001, Brian Tanner wrote: Brian Foddy actually brings up a really important issue, which would go along way to making (at least me) much happier with the proposed change. *If* there

Re: [PHP-DEV] Security Issues

2001-07-28 Thread Heikki Korpela
On Sat, 28 Jul 2001, Zeev Suraski wrote: Anyway, to be more constructive - Andi had an idea when we were catching a cab earlier today (yesterday). His idea (which I'm just pitching, we haven't thought this through at all yet) is that instead of having register_globals on, or off, we would

Re: [PHP-DEV] Security Issues

2001-07-28 Thread Zeev Suraski
At 05:08 27/07/2001, [EMAIL PROTECTED] wrote: Addressed to: Rasmus Lerdorf [EMAIL PROTECTED] [EMAIL PROTECTED] Or you can simply stop these people from using PHP which is another effect turning off register_globals will have. Java does not have this problem because Java is

Re: [PHP-DEV] Security Issues

2001-07-28 Thread Hartmut Holzgraefe
Zeev Suraski wrote: Anyway, to be more constructive - Andi had an idea when we were catching a cab earlier today (yesterday). His idea (which I'm just pitching, we haven't thought this through at all yet) is that instead of having register_globals on, or off, we would have it as unset, by

Re: [PHP-DEV] Security Issues

2001-07-28 Thread Phil Driscoll
Apologies in advance to Zeev for arguing on this one, but be assured I firmly believe that your solution would be to the detriment of PHP and a better solution is possible :) On Saturday 28 July 2001 12:44, Zeev Suraski wrote: NO!! :) Saying people would stop using PHP (or won't get

Re: [PHP-DEV] Security Issues

2001-07-28 Thread Heikki Korpela
On Sat, 28 Jul 2001, Zeev Suraski wrote: BTW, I'm just being argumentative here. I personally think that having E_NOTICE on is a very good idea, and that apps should be E_NOTICE-clean. A great deal of PHP programmers will not agree with me, though, so I haven't made up my mind on whether I

Re: [PHP-DEV] Security Issues

2001-07-28 Thread Zeev Suraski
- My mind is pretty firm about implementing shortcuts for $HTTP_*_VARS. People are going to rebel big time if we remove their global variables by default, and make them use these exceptionally long alternatives instead. Most people I talked to (virtually all of them except for you :) agreed

Re: [PHP-DEV] Security Issues

2001-07-28 Thread Andi Gutmans
Hey, I thought of an idea yesterday which could make everyone happy. In the default php.ini we set the register_globals to a new value unset. If PHP runs with this INI value it will display a page telling you that you need to define the register_globals option in your php.ini and explains the

Re: [PHP-DEV] Security Issues

2001-07-28 Thread Stig S. Bakken
Björn Schotte wrote: * Rasmus Lerdorf wrote: significantly more secure PHP scripts out there. It will simply cause scripts to break in non-obvious ways and the knee-jerk fix will be to swear at those annoying PHP folks and then turn register_globals on, or they will do something like:

Re: [PHP-DEV] Security Issues

2001-07-28 Thread Ron Chmara
On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote: At 06:01 28/07/2001, Phil Driscoll wrote: I and no doubt thousands of others will turn register_globals on because it gives much more readable code, much less typing and does not IMHO add one jot to the security of my

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 08:48 26/07/2001, Rasmus Lerdorf wrote: Just replace your if ($ok) with if (!empty($ok)), and you have a perfect exploitable code that produces no warnings. But in this case someone has gone to the trouble to figure out what empty() does. And generally they use empty() on things that

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Cynic
At 08:32 7/27/2001, Zeev Suraski wrote the following: -- Zeev, while I'll applaud to the changes you propose, I suggest this happens in 4.1. I know, this is really a cosmetic change only, and doesn't justify the bump from the

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
Well, we actually could just bump the version number to 4.1.0 for these changes alone. I don't think we should wait for *any* of the other changes that people had in mind for a major or semi major version, but bumping the number to 4.1.0 instead of staying at 4.0.8 is probably a good idea.

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Heikki Korpela
On Thu, 26 Jul 2001, Zeev Suraski wrote: But in this case someone has gone to the trouble to figure out what empty() does. And generally they use empty() on things that come from the user anyway. I don't think I have ever seen people use empty() to check to see if they themselves have set

RE: [PHP-DEV] Security Issues

2001-07-27 Thread Marc Boeren
accept_parameters($user_string); // or something similar register_globals off. $user_string=$HTTP_POST_VARS[user_string]; This accomplishes the same thing as your example, and doesn't introduce any new syntax... I don't really see the advantage of the accept_parameters idea. Well, the

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Rasmus Lerdorf
At 08:48 26/07/2001, Rasmus Lerdorf wrote: Just replace your if ($ok) with if (!empty($ok)), and you have a perfect exploitable code that produces no warnings. But in this case someone has gone to the trouble to figure out what empty() does. And generally they use empty() on things

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Cynic
At 10:35 7/27/2001, Rasmus Lerdorf wrote the following: -- I actually think that turning E_NOTICE on is going to have a huge effect on a mind boggling number of scripts, probably on the same order of magnitude as setting

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 01:35 27/07/2001, Rasmus Lerdorf wrote: I think you missed my point. People use empty() and isset() on a variable to check to see if that variable was set by the user. As such that variable is unclean and whether it came in via register_globals or not is quite irrelevant. If it is unclean

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Rasmus Lerdorf
At 01:35 27/07/2001, Rasmus Lerdorf wrote: I think you missed my point. People use empty() and isset() on a variable to check to see if that variable was set by the user. As such that variable is unclean and whether it came in via register_globals or not is quite irrelevant. If it is

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Björn Schotte
* Rasmus Lerdorf wrote: significantly more secure PHP scripts out there. It will simply cause scripts to break in non-obvious ways and the knee-jerk fix will be to swear at those annoying PHP folks and then turn register_globals on, or they will do something like:

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Peter Petermann
I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more secure scripts/applications.

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 03:09 27/07/2001, Rasmus Lerdorf wrote: At 01:35 27/07/2001, Rasmus Lerdorf wrote: I think you missed my point. People use empty() and isset() on a variable to check to see if that variable was set by the user. As such that variable is unclean and whether it came in via

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
Guys, Please read the advisory. You simply can't say that register_globals=off wouldn't have resulted in more secure apps, because there are *3* examples (or more, I don't remember) there of applications that would have not been exploitable had register_globals=on was in effect! Unless we

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 20:22 02/01/1999, Peter Petermann wrote: I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 03:36 27/07/2001, Zeev Suraski wrote: Guys, Please read the advisory. You simply can't say that register_globals=off wouldn't have resulted in more secure apps, because there are *3* examples (or more, I don't remember) there of applications that would have not been exploitable had

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Alexander Wagner
Peter Petermann wrote: I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more secure

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Peter Petermann
register_globals is off? Of course not, but it's definitely going to knock down a huge amount of exploits in their apps, and there are good chances that these would be the only exploits in it. as rasmus wrote, this would only result in users using foreach to do that. you cant fight

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Peter Petermann
what we could do to make people to write more secure script is: - telling them to do so, - telling them what is insecure - telling them why something is insecure - writing a special type of documentation, about how to write secure scripts Please, can you say beginner? Once people

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 20:53 02/01/1999, Peter Petermann wrote: register_globals is off? Of course not, but it's definitely going to knock down a huge amount of exploits in their apps, and there are good chances that these would be the only exploits in it. as rasmus wrote, this would only result in users

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 20:58 02/01/1999, Peter Petermann wrote: i dont think it is easier to write more secure applications with turning a feature of. Read the advisory before your next post or I'll have Kristian smack you the next time he sees you! :) Zeev -- PHP Development Mailing List http://www.php.net/

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Björn Schotte
* Zeev Suraski wrote: equivalent to shipping cars without brakes. You hope that the user would be bright enough to install brakes, Hoping that is not enough. If you really change the behaviour to ship PHP with register_globals to off, then I suggest you should also ship some README_Security

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Alexander Wagner
Peter Petermann wrote: i dont think it is easier to write more secure applications with turning a feature of. In this particular case, it would. There are several reported cases of security-holes caused by this feature. Without it, there would be fewer insecure PHP-applications out there.

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Phil Driscoll
I must be much more stupid than I give myself credit for. Changing to register globals=off surely does very little in terms of security for the easily fakeable GPC variables. I can see that for environment variables the picture is slightly different - you do need to be sure that this *really*

RE: [PHP-DEV] Security Issues

2001-07-27 Thread Marc Boeren
Changing to register globals=off surely does very little in terms of security for the easily fakeable GPC variables. Maybe not for these variables, but other variables used in your script cannot be faked by passing them as HTTP_POST_VARS. e.g., with register_globals=off if

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Phil Driscoll
On Friday 27 July 2001 12:51, Marc Boeren wrote: if ($internal_variable == 'whatever') { // do something, knowing that a user could never have set this } The second check is where a lot of scripts are exploitable, I think, if register_globals=on, because programmers do not expect

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Peter Petermann
(b) As I said, if someone wants to use a gun to shoot himself in the head, he's welcome to do so. The least we could do is hand him the gun safely pointed in the other direction, and not point it to his brain. we are not talking about people who want to have security holes, we are talking

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Heikki Korpela
On Fri, 27 Jul 2001, Zeev Suraski wrote: (a) How about just setting register_globals to on? We're not talking about taking this option away, for now, just turn it off by default. (b) As I said, if someone wants to use a gun to shoot himself in the head, he's welcome to do so. The least we

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Rasmus Lerdorf
Peter Petermann wrote: I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Rasmus Lerdorf
Peter Petermann wrote: i dont think it is easier to write more secure applications with turning a feature of. In this particular case, it would. There are several reported cases of security-holes caused by this feature. Without it, there would be fewer insecure PHP-applications out

RE: [PHP-DEV] Security Issues

2001-07-27 Thread Brian Tanner
- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: July 25, 2001 6:29 PM To: Rasmus Lerdorf Cc: Andy; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Security Issues At 07:31 25/07/2001, Rasmus Lerdorf wrote: Because not everyone agrees that this is actually highly recommended. Most third-party PHP

Re: [PHP-DEV] Security Issues

2001-07-27 Thread John Donagher
On Fri, 27 Jul 2001, Zeev Suraski wrote: It will simply cause scripts to break in non-obvious ways and the knee-jerk fix will be to swear at those annoying PHP folks and then turn register_globals on, or they will do something like: foreach($HTTP_POST_VARS as $key=$val) $$key =

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Jason Greene
Wagner [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, July 27, 2001 9:37 AM Subject: Re: [PHP-DEV] Security Issues Peter Petermann wrote: I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 04:33 27/07/2001, Phil Driscoll wrote: I must be much more stupid than I give myself credit for. Changing to register globals=off surely does very little in terms of security for the easily fakeable GPC variables. I can see that for environment variables the picture is slightly different -

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 04:48 27/07/2001, Peter Petermann wrote: well, i think you misunderstood me. we are not talking of a brakeless car, and we are not talking about a language who is not able to be used secure. we are talking about something that has the abilities to be secure, we just need to teach the people

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 07:37 27/07/2001, Rasmus Lerdorf wrote: I see your point, but I disagree. Register_globals is a lanugage-feature which can result in security-gaps when people don't initialize their variables. It's a common mistake, a pitfall, especially for beginners, that could be resolved by

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 07:44 27/07/2001, Rasmus Lerdorf wrote: Peter Petermann wrote: i dont think it is easier to write more secure applications with turning a feature of. In this particular case, it would. There are several reported cases of security-holes caused by this feature. Without it, there

RE: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 10:19 27/07/2001, Brian Tanner wrote: Is all of this springing from that security advisory that was published a short while ago? I remember reading that, and feeling that many of the issues were overblown (if I'm thinking of the same one). Also, wasn't that advisory just written by some guy?

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
I'm definitely in favour of that, and some of the other suggestions that were raised. We won't be able to make all steps at once, but whomever can contribute is obviously quite welcome to do so. Zeev At 04:15 27/07/2001, Björn Schotte wrote: * Zeev Suraski wrote: equivalent to shipping

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 10:01 27/07/2001, Rasmus Lerdorf wrote: That's also not true. Is using $foo all that better than $_GET[foo]? For a neophyte user - most definitely. But it isn't. It's by fixing an inherent design flaw in PHP. The proposed target situation is *NOT* any more difficult to the users

RE: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 04:51 27/07/2001, Marc Boeren wrote: Changing to register globals=off surely does very little in terms of security for the easily fakeable GPC variables. Maybe not for these variables, but other variables used in your script cannot be faked by passing them as HTTP_POST_VARS. e.g., with

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Phil Driscoll
On Friday 27 July 2001 17:35, Zeev Suraski wrote: Have you read the advisory? That's simply not true. Yes, and I beleive it is true in most cases. There are two main types of security problems related to this: (a) Ones that originate in the fact that people don't know they mustn't trust

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 08:58 27/07/2001, Jason Greene wrote: I have been watching this thread for too long and I can no longer resist commenting. If a programmer does not initialize SECURE variables properly, he is going to make far worse security decisions in his software. Next thing we are going to hear is

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Rasmus Lerdorf
That's also not true. Is using $foo all that better than $_GET[foo]? For a neophyte user - most definitely. But it isn't. It's by fixing an inherent design flaw in PHP. The proposed target situation is *NOT* any more difficult to the users than the situation is today. Of course it is.

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Zeev Suraski
At 10:26 27/07/2001, Phil Driscoll wrote: On Friday 27 July 2001 17:35, Zeev Suraski wrote: Have you read the advisory? That's simply not true. Yes, and I beleive it is true in most cases. There are two main types of security problems related to this: (a) Ones that originate in the fact

RE: [PHP-DEV] Security Issues

2001-07-27 Thread Brian Tanner
: [PHP-DEV] Security Issues At 10:19 27/07/2001, Brian Tanner wrote: Is all of this springing from that security advisory that was published a short while ago? I remember reading that, and feeling that many of the issues were overblown (if I'm thinking of the same one). Also, wasn't that advisory

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Rasmus Lerdorf
This is an important step, that as I said, I wanted to make for years. I just argue that as protective as you are over register_globals=on, the real flaw is there, and this is the place it should be fixed. Fixing the fact that E_NOTICE is on may also be viable, but in practice: - A huge

Re: [PHP-DEV] Security Issues

2001-07-27 Thread
In article [EMAIL PROTECTED], Rasmus Lerdorf wrote: But that's not the point. The point is that people who don't care about security or coding style (beginners or professionals, doesn't really matter) are less likely to write insecure code, because there's one mistake less that they can

Re: [PHP-DEV] Security Issues

2001-07-27 Thread Brian Foddy
Zeev Suraski wrote: Because it's a matter of taste, and different people see things different ways. Personally I find $_GET[foo] much clearer than $foo. It tells me, beyond a reasonable doubt, where this thing is coming from. The one and only drawback I see for this method is that it's a

RE: [PHP-DEV] Security Issues

2001-07-27 Thread Brian Tanner
Brian Foddy actually brings up a really important issue, which would go along way to making (at least me) much happier with the proposed change. *If* there will be: $_Get[] $_Post[] $_Cookie[] -- can we also have something else to the tune of: $_External or $_User or $_Something That gets

  1   2   >