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

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 PLEASE!

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

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 throu

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

Zeev Suraski ([EMAIL PROTECTED]) wrote: > I don't think we can change the behavior of empty() at this stage... isempty()? -- PHP Development Mailing List To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list admin

Re: [PHP-DEV] Security Issues

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 fro

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

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 publ

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

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 thou

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

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 message

Re: [PHP-DEV] Security Issues

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

Re: [PHP-DEV] Security Issues

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 oth

Re: [PHP-DEV] Security Issues

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 langu

Re: [PHP-DEV] Security Issues

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 enric

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

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 emp

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

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 replace

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

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 ([E

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

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 ju

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

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.  An

Re: [PHP-DEV] Security Issues

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

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, isset

Re: [PHP-DEV] Security Issues

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 chance

Re: [PHP-DEV] Security Issues

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 normal

Re: [PHP-DEV] Security Issues

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 muc

Re: [PHP-DEV] Security Issues

UNSUBSCRIBE ME PLEASE!! "Stig S. Bakken" schrieb: 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

Re: [PHP-DEV] Security Issues

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 >> typin

Re: [PHP-DEV] Security Issues

UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 06:01 28/07/2001, Phil Driscoll wrote: >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 J

Re: [PHP-DEV] Security Issues

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

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 tal

FW: [PHP-DEV] Security Issues

Just passing this along form Ramsi... who sent it to me instead of the list.   (unless he wants to unsubscribe from my point of view :P )-Original Message-From: Ramsi Sras [mailto:[EMAIL PROTECTED]]UNSUBSCRIBE ME PLEASE!! Brian Tanner schrieb: Brian Foddy actually bri

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

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 'bad

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

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 eas

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

> 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. Tha

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

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 > fu

Re: [PHP-DEV] Security Issues

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

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 functio

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

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 > >> t

Re: [PHP-DEV] Security Issues

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 fixin

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

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 somethi

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

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 f

Re: [PHP-DEV] Security Issues

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 availa

Re: [PHP-DEV] Security Issues

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 darn

Re: [PHP-DEV] Security Issues

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

Re: [PHP-DEV] Security Issues

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 throu

Re: [PHP-DEV] Security Issues

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

Re: [PHP-DEV] Security Issues

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

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 someth

Re: [PHP-DEV] Security Issues

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 th

Re: [PHP-DEV] Security Issues

At 06:01 28/07/2001, Phil Driscoll wrote: >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

Re: [PHP-DEV] Security Issues

- 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

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 whethe

Re: [PHP-DEV] Security Issues

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 starte

Re: [PHP-DEV] Security Issues

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

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 b

Re: [PHP-DEV] Security Issues

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 woul

RE: [PHP-DEV] Security Issues

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* th

RE: [PHP-DEV] Security Issues

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 th

Re: [PHP-DEV] Security Issues

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 automat

RE: [PHP-DEV] Security Issues

On Fri, 27 Jul 2001 23:00:54 +0200, "Brian Tanner" <[EMAIL PROTECTED]> wrote: > *If* there will be: > > $_Get[] > $_Post[] > $_Cookie[] > > -- can we also have something else to the tune of: > > $_External or $_User or $_Something Important point. It's stupid if we suddenly have to hard-code

Re: [PHP-DEV] Security Issues

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 so complex that this > same set of users

RE: [PHP-DEV] Security Issues

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 pop

Re: [PHP-DEV] Security Issues

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'

Re: [PHP-DEV] Security Issues

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 the

Re: [PHP-DEV] Security Issues

> 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 hug

RE: [PHP-DEV] Security Issues

Cc: [EMAIL PROTECTED] Subject: RE: [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'

Re: [PHP-DEV] Security Issues

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 i

Re: [PHP-DEV] Security Issues

> 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

Re: [PHP-DEV] Security Issues

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

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 > trus

RE: [PHP-DEV] Security Issues

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

Re: [PHP-DEV] Security Issues

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

Re: [PHP-DEV] Security Issues

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 c

RE: [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 just written by som

Re: [PHP-DEV] Security Issues

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

Re: [PHP-DEV] Security Issues

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 resolve

Re: [PHP-DEV] Security Issues

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 peopl

Re: [PHP-DEV] Security Issues

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

AIL PROTECTED]> To: "Alexander 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 &g

Re: [PHP-DEV] Security Issues

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=>$va

RE: [PHP-DEV] Security Issues

the mind of either group. -Brian T -Original Message- 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 th

Re: [PHP-DEV] Security Issues

> 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 o

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 knows what and how to do nowadays. > > > I don't think turning register_globals to off will evangelize > > > people t

Re: [PHP-DEV] Security Issues

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

Re: [PHP-DEV] Security Issues

> (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 talkin

Re: [PHP-DEV] Security Issues

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 expe

RE: [PHP-DEV] Security Issues

> 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 ($HTTP_POST_V

Re: [PHP-DEV] Security Issues

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

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

* 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

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

Re: [PHP-DEV] Security Issues

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

Re: [PHP-DEV] Security Issues

> > 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"?

Re: [PHP-DEV] Security Issues

> 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 s

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 knows what and how to do nowadays. > > I don't think turning register_globals to off will evangelize > > people to develop mo

Re: [PHP-DEV] Security Issues

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 r

Re: [PHP-DEV] Security Issues

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 >

Re: [PHP-DEV] Security Issues

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 mak

Re: [PHP-DEV] Security Issues

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 reg

Re: [PHP-DEV] Security Issues

> 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

* 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: > > foreach($HTTP_POS

Re: [PHP-DEV] Security Issues

> 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

Re: [PHP-DEV] Security Issues

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 unclea

Re: [PHP-DEV] Security Issues

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 registe

  1   2   >