I think I did code well (everybody can say the code is 100% proof - until get hacked ;-)) and never, for these 7 years had problems. And I'm sure the site will be just ok if I switch register_globals back to On through .htaccess. Actually, I offered the client 3 options: 1. redo the website (after 7 years, it's really time to do that :-)); 2. fix the code but keep the site the same; 3. change .htaccess. the site will work just fine;
though, I also think, if you built your code with register_globals on several years ago, you are still in a danger. Big or small, depends on your code, but still in risky group. right?
anyway, the client was really understandable and we are going most likely to build new website.
thanks for opinions and help.
ll
________________________________
From: Jim Lucas <lists@xxxxxxxxx>
To: Robert Cummings <robert@xxxxxxxxxxxxx>
Cc: Nathan Rixham <nrixham@xxxxxxxxx>; Richard Heyes <richard@xxxxxxx>; lamp.lists@xxxxxxxxx; "php-general@xxxxxxxxxxxxx" <php-general@xxxxxxxxxxxxx>
Sent: Thursday, January 8, 2009 10:51:32 AM
Subject: Re: redoing website after 7 years
Robert Cummings wrote:
> On Wed, 2009-01-07 at 16:16 -0800, Jim Lucas wrote:
>> Nathan Rixham wrote:
>>> Richard Heyes wrote:
>>>>> but, I'm more concern does client has to pay the changes/upgrade or
>>>>> it's still "my obligation"?
>>>> Of course you charge him. Christ if I was expected to maintain stuff
>>>> gratis that I wrote 7 years ago I'd be mullahed.
>>>>
>>> concurred, personally I'd be tempted to offer to find or indeed resetup
>>> on an old server if they could find one for free, but as for upgrading
>>> certainly quote/charge.
>>>
>> If one was to go this route, then why not just use a .htaccess file and turn on register_globals and
>> call it good?
>>
>> I mean really, the customer would be in no greater risk then what they had been for the last 7 years.
>>
>> Reason being, nothing else has changed about the script. If their is an exploit in the script now,
>> then their was an exploit in the past.
>>
>> I realize that I am going against what I preach here. But really, the ISP isn't going to pay for
>> it. The own isn't going to want to pay for it. Can't squeeze blood from a turnip...
>
> What if the turnip is the programmer?
>
In this case, it wouldn't be.
>> If the programmer designed an insecure web site 7 years ago then the programmer should be
>> responsible for making the application secure. That was part of his/her job in the beginning.
>
> Nobody said it's insecure... only that register globals was used as a
> feature, a feature at one point touted as useful to the PHP language. As
> has been mentioned previously, register globals is not real culprit of
> insecurity in this context, the real culprit is poor programming while
> using register globals... unfortunately such programming was common thus
> requiring a strong antidote... namely the downstream removal of support
> for the feature.
>
I didn't mean to imply that the programmer did build an insecure app. I said "if the programmer designed and insecure web site".
If the designer didn't build an insecure app, then it wont hurt a thing to turn on register_globals and just go back to the way it was before the ISP
upgraded.
>> I mean, sure when I first started designing/building web sites I thought I was doing the right thing
>> most of the time. If two years down the road I had a moment of clarity and I realized that I had
>> been doing something wrong or in-secure for the past two years (which I've done) then I would go
>> back and tell the customer that I did something wrong or in-secure and I would fix it for free.
>
> Ahhh... but this presumes the programmer did something wrong. That has
> not yet been determined. All we know is that globals were used, not that
> they were necessarily used incorrectly.
>
I didn't say that, nor did I mean to imply that. I was talking about my experiences.
>> Thia is part of my responsibility as a designer
>>
>> With that said, I would image that over the past 7 years, if the site has not been exploited, then I
>> would think that by turning register_globals back on would be of no concern.
>>
>> To me, all the above sounds logical. If I am missing something, please point it out.
>
> Duly pointed out ;)
>
> Cheers,
> Rob.
So, here is how I would summarize all the above.
Whether or not the programmer used the feature register_globals isn't of concern.
Whether the programmer designed and insecure app is the concern.
<?php
$APP_SECURE = (app is secure?); // Boolean: TRUE, FALSE
if ( $APP_SECURE ) {
print('Turn on register_globals and call the job done.');
} else {
print('Fix, at no cost, what you designed insecurely.');
}
?>
--
Jim Lucas
"Some men are born to greatness, some achieve greatness,
and some have greatness thrust upon them."
Twelfth Night, Act II, Scene V
by William Shakespeare
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
