________________________________
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
sorry for top-posting in my previous email. errarer humanum est!
:-)
ll
