On 15-Dec-06, at 4:58 PM, Stanislav Malyshev wrote:
Ok this is better, but it will break every single application out
there. I for one think that this is unacceptable.
Well, initially - yes. With some tweaking like using automatic
filters taint-safeguarding should not be too hard though (this
would be one of the milestones - if we can't make it easy, the
whole idea is doomed). And yes, it definitely makes it unusable as
default production mode - but that's not the intended mode - not at
least until people would make writing taint-safe code the routine :)
All it means is extra work for developers with little or no tangible
benefits. I also wonder how taint will work with the standard remove/
add slashes wrapper most large apps implement now a days that
effectively modifies every input variable going into the application.
usually are synonymous with insecure. The biggest issue with
safe_mode (and I suspect tainting as well) is the faulty
assumption that if you enable it, you get instant security and you
can quite being paranoid. Which leads to false sense of security
and eventually getting hacked.
I think the issue with safe mode is the "mark unsafe" approach -
which, when applied to very rich and diverse environment such as
PHP is bound to fail to provide comprehensive security, thus
leading to the problems you describe.
The job of a language is to provide tools, not arbitrary crippling
limitation under the guise of security improvement.
So you reverse the problem, you'd still need to examine every
function and determine which of its parameters can be tainted and
which cannot.
Not necessarily. If I have some obscure libWhateverFoo extension, I
can just say "OK, I don't know what this does, but please filter/
untaint data before feeding them to it" and for that I don't even
need to touch the extension itself. This would not be 100% since
the user may just not know that passing string "pleasekillme" to
this extension would blow up his data center, but at least we would
make user consider the fact that he passes external data to the
extension and make decision. :)
So that means I now need to do pointless call even in instances where
untainted data would be perfectly safe, nice.
Also, if you talk about standard functions like strlen, demanding
to untaint all data before calling strlen would be rather harsh, so
yes, we would have to go over many functions. It is definitely not
a half-an-hour work, and it definitely would require some deep
consideration and discussion, but if we always prefer to err on the
safe side - and remember, we would not need any effort to be on the
safe side - I think we could make it work reasonable well.
safe_mode sounded like a really reasonable idea too, I would've hoped
some lessons from past mistakes could be made.
and let people decide what and where things should be used. Doing
automated validation is prone to error and we are almost
guaranteed to never get it right.
No, I do not propose to do automatic validation. I only present a
choice when we would ask the user to decide if the data is
validated enough to be untainted - we can do it as explicit as
requiring specific filter function call, or as implicit as making
many filtering functions such as htmlspecialchars functions as
cleaners. I tend to be somewhere in between, but that's exactly the
place where more feedback would be very useful.
If choice is equivalent to forcing the user to untainted all data,
then I suppose you're right.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
