Please allow me to introduce myself briefly: I'm Wietse Venema from
IBM Research, also known as the creator of the open source Postfix
mail system, co-author of the Coroner's toolkit and SATAN, and the
original author of TCP Wrapper. That doesn't mean everything I touch
becomes gold; if it did then I'd be a very rich man now :-)
This is a proposal to add basic Perl/Ruby like tainting support to
PHP: an option that is turned off by default, and that programmers
may turn on at runtime to alert them when they make the common
mistake of using uncleansed input with include, echo, system, open,
etc. This would work with unmodified third-party extensions.
Taint support is first of all an education tool. When an alert is
raised that data needs cleansing, the programmer needs to make a
conscious decision. It's their job to choose the right method. I'll
discuss below why I think PHP shouldn't make the decision for them.
Taint support is not a sandbox; a malicious PHP script can still
open a pipe to a shell process and feed uncleansed commands to it.
Taint support can be an ingredient to build a sandbox, but that
involves lots more. See for example the Ruby reference at the end.
Of course when overhead is low enough, people might want to turn
on taint checks in production, to implement a multi-layer defense.
Wise people know that no single layer provides perfect protection.
People already do this with other scripting languages.
Last month I did a proof of concept implementation to raise an alert
when raw network data is passed to a few PHP primitives (echo/print,
system/exec, eval/include, open stream, and manipulate file/directory).
If this proposal survives review, then I could spend a chunk of
time in 2007 working out more details and doing a full production
quality implementation.
Before I discuss my taint proposal details I first want to explain
why I see problems with other approaches.
Why not have PHP automatically detect and cleanse malicious data?
In preparation for this I studied several years worth of literature
about making PHP etc. applications "secure" (see references at the
end). I found that many researchers have worked on systems that
try to secure PHP etc. applications without changing PHP script
source code.
These systems explicitly permit the use of uncleansed data in
html/shell/sql commands. When an html/shell/sql request contains
"forbidden" characters in certain positions, these systems either
"neuter" the request before execution, or they abort the request.
In the normal case where requests contain benign inputs only, no-one
will ever notice that these protections exist, except perhaps by
their lack of responsiveness.
I see many problems with systems that do automatic data cleansing.
The main problems are not technical but psychological:
-
Education: automatic cleansing systems don't make programmers
aware that network data is inherently untrustworthy. Instead,
they teach the exact opposite: don't worry about data hygiene.
This of course means they will get bitten elsewhere anyway. -
Expectation: automatic cleansing systems have to be perfect. If
the safety net catches some but not all cross-site scripting or
SQL injection attacks, then the system has a security hole and
people lose confidence. This gives security a bad reputation.
These two problems are inherent to all solutions that automatically
fix security problems for the programmer. They encourage programmers
to write sloppy code. I want to help them write better code instead.
But wait, there is more :-) There are technical problems, too:
-
Overhead: as strings are sliced, diced, and tossed around, the
automatic cleansing safety net has to keep track of exactly which
characters in a substring are derived from untrusted input, and
which characters are not, so that the safety net can later recognize
malicious content in the middle of html/shell/sql/etc. commands. -
More overhead: special-purpose code is needed in all functions
and all primitives that execute html/shell/sql/etc. commands.
This code is needed because each context has a different definition
of what is "malicious" content in the middle of a request. -
Collateral damage: providers of PHP extensions need to implement
their own special-purpose code to detect or neuter untrusted
substrings in inputs, or to mark untrusted substrings in return
values, otherwise the safety net is incomplete, and the PHP
extension introduces a security hole.
Compared to this, the run-time overhead of maintaining and testing
taint bits in PHP is miniscule, if my experiences with the prototype
are meaningful.
A first look at PHP taint support
The general idea is to mark certain external inputs as tainted (ex:
network, file), and to disallow the use of tainted data with certain
operations that change PHP's own state (ex: include, eval), or that
access or modify external state (ex: create/open/remove file; connect
to server; generate HTML; execute shell command; execute database
command).
The exact definitions of what inputs are tainted and what operations
are sensitive will need to be made more precise later (lots of
opportunity for splitting fine hairs). For now I want to focus on
the general mechanism.
The following is a high-level view of what would happen when taint
checking is turned on at run-time:
-
Each ZVAL is marked tainted or not tainted (i.e. we don't taint
individual characters within substrings). Black and white is all.
In some future, someone may want to explore the possibility of
more than two shades. But not now. -
Primitives and functions such as echo, eval, or mysql_query are
not allowed to receive tainted input. When this happens the script
terminates with a run-time error. It is a bad idea for software
to continue after a security violation. -
PHP propagates taintedness across expressions. If an input to
an expression is tainted, then the result of that expression is
tainted too. There are exceptions to this rule: these are called
sanitisers, as discussed next. -
The PHP application programmer untaints data by explicit assignment
with an untainted value. For example, the result fromhtmlentities()
or mysql_real_escape_string() is not tainted. People could apply
the wrong sanitizer if they really want to. Remember, the purpose
is to help programmers by telling what data needs cleansing. It
is up to them to make the right decision. If we wanted to force
the use of the "right" sanitizer then we would need multiple
shades of untaintedness. This would not be practical.
That's the high-level view. At a lower level we make trade-offs
between usability, implementation cost, maintenance cost, run-time
cost, and more. In particular, my goal is to support taint with
third-party extensions, but without changes to the source code of
those extensions.
Thus, compromises need to be found, and some perfection needs to
be sacrificed. I'm aiming for "useful" instead of "impossible".
Categorizing the functions and primitives
Before we get into the nitty-gritty of tainting and untainting we
first need to categorize functions and primitives according to their
inputs and results.
-
Some functions or primitives are not allowed to receive tainted
input; the script is terminated instead. These functions or
primitives are called sensitive. -
Some functions or primitives always return an untainted result.
These functions or primitives are called sanitisers. -
Some functions or primitives return a tainted result only when
their input is tainted. For example, if $x is tainted, then the
return value of substr($x, whatever) is tainted too. I'm still
looking for good name for this function or primitive category
("permeable"? The term should appeal to non-English speakers,
including myself). -
Some functions or primitives always return tainted results. For
example, results from mysql_query must be sanitized before use
in a sensitive context such as echo or print, or in an SQL query(!);
this prevents "stored cross-site scripting" and SQL injection
problems. I'm still looking for good name for this function or
primitive category (tainter?).
mysql_query is an example of a function that is at the same time
sensitive and a tainter: it can receive only untainted input, and
its results are always tainted.
If we want to support taint checking with third-party PHP extensions,
but without changes to their source code, then all we need at this
point is a table that says which functions are sensitive and/or
tainters, and so on. If no information is available about a specific
function we could assume the worst: when taint checking is turned
on at runtime, an uncategorized function would not be allowed to
receive tainted inputs, and its results would always be tainted.
All this categorization of functions makes no difference to how
applications run, until someone actually turns on taint checking
at run-time. It is therefore completely backwards compatible, even
when the function category information is incorrect or incomplete.
Setting taint
Obviously, data from the network and from databases needs to be
marked as tainted. Less obvious is if we want to go as far as Perl,
and also taint the current directory and a bunch of other things.
More study is needed. Although these decisions will greatly impact
usability, they can be made later, because they don't really affect
the over-all design or implementation of the system.
Propagating taint
At this level things start to become interesting. Within the PHP
core we have a large amount of control over how taint is handled,
so we can spend a lot of time splitting fine hairs. With third-party
extensions we are very much limited by the requirement that taint
checking must not require source code changes to those extensions.
-
Within the PHP core, taint propagation can be fine-grained. For
example, we could decide that substr(string, start, length) returns
a tainted result only if the string argument is tainted; a tainted
start or length argument would not affect the taintedness of the
result. For comparison, Perl even taints the result when the start
argument is tainted; with Ruby, numbers can't be tainted, so the
issue with a tainted start or length values does not even exist.
This is just one example of splitting fine hairs. -
With PHP extensions, taint detection and propagation can happen
only at the function interface (the functions themselves aren't
taint-aware, unless their implementor went through the effort).
If an extension function is allowed to receive tainted input,
then its return value is also tainted unless the function is
classified as a sanitizer. With extensions that receive complex
arguments such as arrays, there is an increased cost as the PHP
core inspects each sub-element for taintedness before making the
actual function call. A similar cost exists with extensions that
return complex tainted results, as the PHP core needs to mark
each sub-element as tainted. These issues may disappear over time
as implementors adopt taint support into their extensions.
Removing taint
This last section gives just a few examples; there are a lot of
detail issues that will need to be considered before we have a
complete system.
-
Removing taintedness requires an explicit assignment. For example,
assigning the result from a sanitizer produces an untainted result. -
Some implementations (Perl) propagate taint across, for example,
string<->number conversions; other implementations consider the
result not tainted (Ruby). More fine hair splitting. -
Testing a variable does not untaint it. For example, if $x is
tainted, the following does not change its taint status:if (some test involving $x) { $x is still tainted here }
The reason for this is entirely practical: we can't reliably
determine if the intention of the test is to sanitize input. -
Testing a tainted variable does not taint the result of expressions
that follow the test. For example, if $y is tainted, the following
code does not taint $x:if ($y == 0) { $x = 0; } else { $x = 1; }
There is one well-known example where such a strategy breaks down,
and that is the degenerate case where a long chain of if/else if/...
statements is used instead of a lookup table:if ($y == 0) { $x = 0; } else if ($y == 1) { $x = 1; } else ...
Remember that my purpose is to help the programmer; my purpose
is not fighting programmers who insist on writing bad code. After
all, they can always open a pipe to a shell process and execute
uncleansed commands there.
This is just the beginning of a long list of things that need to
be looked into, but I will stop here for now.
Conclusion
This is a proposal to add run-time taint checking to PHP. It is not
a sandbox for the execution of hostile code. It is just a tool to
help programmers find places where they need to sanitize data. It
avoids changes to third-party extensions, and is turned off by
default. It is therefore completely backwards compatible.
Last month I did a proof of concept implementation that protects a
few PHP primitives. If this proposal survives review, then I could
spend a chunk of time in 2007 working out the details doing a full
production quality implementation.
References
The Perl taint feature has been an example for many other efforts.
http://perldoc.perl.org/perlsec.html
Ruby implements multiple levels of taint checking. The lowest level
is like Perl. The highest level is a sandbox where code can neither
create nor modify untainted objects, read/write files or sockets,
etc. At this level, my claim that "the programmer can always open
a pipe to a shell and execute uncleansed commands there" is no
longer true. http://www.rubycentral.com/book/taint.html
Wei Xu, Sandeep Bhatkar, R. Sekar: "Taint-Enhanced Policy Enforcement:
A Practical Approach to Defeat a Wide Range of Attacks". 15th USENIX
Security Symposium Vancouver, BC, Canada, August 2006.
http://seclab.cs.sunysb.edu/sandeep/pubs/papers/taint_usenixsec06.pdf
Source-to-source transformation to instrument source code with
taint tracking. They use a rule-based policy to disallow tainted
metacharacters shell/sql commands, format strings, html tags etc.
Modest overhead.
Alex Ho, Michael Fetterman, Christopher Clark, Andrew Warfield, and
Steven Hand: "Practical TaintBased Protection using Demand Emulation".
Eurosys2006, Leuven, Belgium, April 2006.
http://www.cl.cam.ac.uk/~akw27/papers/taint-eurosys06.pdf
http://www.cs.kuleuven.ac.be/conference/EuroSys2006/papers/p29-ho.pdf
This work uses Xen virtualisation for code that handles untainted
data, and switches to Qemu emulation for code that touches
tainted data. Unlike anyone else they also taint individual
disk blocks, as the process writes tainted data to file.
J. Newsome and D. Song: "Dynamic Taint Analysis: Automatic Detection,
Analysis, and Signature Generation of Exploit Attacks on Commodity
Software". Network and Distributed Systems Security Symposium,
February 2005. http://www.ece.cmu.edu/~dawnsong/papers/taintcheck.pdf
Binary-to-binary translation with valgrind. Significant overhead.
A. Nguyen-Tuong, S. Guarnieri, D. Greene, J. Shirley, and D. Evans.
"Automatically hardening web applications using precise tainting."
20th IFIP International Information Security Conference, 2005.
http://www.cs.virginia.edu/evans/pubs/infosec05.pdf
Precise taint tracking using a modified PHP engine. Tainted
data is forbidden (ex: SQL queries, system functions) or sanitized
(ex: HTML output). Data from SQL database is considered tainted.
Careful parsing of SQL, HTML to prevent command injection and
cross-site scripting via tainted operators or tags. Low overhead.
Tadeusz Pietraszek, Chris Vanden Berghe: "Defending Against Injection
Attacks Through Context-Sensitive String Evaluation". Recent
Advances in Intrusion Detection (RAID), 2005.
http://chris.vandenberghe.org/publications/csse_raid2005.pdf
Precise taint tracking using a modified PHP engine. Taint-awareness
requires modifications to built-ins and to extensions. Careful
parsing of SQL etc. to prevent command injection. Modest overhead.
Yao-Wen Huang, Fang Yu, Christian Hang, Chung-Hung Tsai, D. T. Lee,
Sy-Yen Kuo: "Securing Web Application Code by Static Analysis and
Runtime Protection". Proceedings of the 13th international conference
on World Wide Web (May 2004).
http://www2004.org/proceedings/docs/1p40.pdf
Hybrid system: a static source analyzer identifies code that
may be vulnerable, then inserts sanitizer code that appears to
be missing. Very low overhead.
This is a proposal to add basic Perl/Ruby like tainting support to
PHP: an option that is turned off by default, and that programmers
may turn on at runtime to alert them when they make the common
mistake of using uncleansed input with include, echo, system, open,
etc. This would work with unmodified third-party extensions.
I doubt it is plausible to make it work entirely without touching
external extensions that those extensions may be changing behavior of
data from tainted to un-tainted and vice versa.
Taint support is not a sandbox; a malicious PHP script can still
open a pipe to a shell process and feed uncleansed commands to it.
Taint support can be an ingredient to build a sandbox, but that
involves lots more. See for example the Ruby reference at the end.
Sounds awefuly like yet another safe_mode, something that proclaims
security, yet being unable to provide it.
Of course when overhead is low enough, people might want to turn
on taint checks in production, to implement a multi-layer defense.
Wise people know that no single layer provides perfect protection.
People already do this with other scripting languages.
Unlikely to ever be the case, the overhead of taint modes is
generally quite significant.
- Education: automatic cleansing systems don't make programmers
aware that network data is inherently untrustworthy. Instead,
they teach the exact opposite: don't worry about data hygiene.
This of course means they will get bitten elsewhere anyway.
Most people program not to learn how, but to solve problems. Which is
why automatic filtering has been the holy grail of security as it
allows developers to avoid thinking about input validation beyond the
initial setup and move on with their lives.
- Expectation: automatic cleansing systems have to be perfect. If
the safety net catches some but not all cross-site scripting or
SQL injection attacks, then the system has a security hole and
people lose confidence. This gives security a bad reputation.
Same argument can be made about taint mode, judging by Perl and Ruby
where there are tricks to bypass it, same argument applies.
- Overhead: as strings are sliced, diced, and tossed around, the
automatic cleansing safety net has to keep track of exactly which
characters in a substring are derived from untrusted input, and
which characters are not, so that the safety net can later recognize
malicious content in the middle of html/shell/sql/etc. commands.
If you look at filter, there is no tracking of malicious chars, the
data is simple cleansed of them or rejected all together, this is a
one time event.
- More overhead: special-purpose code is needed in all functions
and all primitives that execute html/shell/sql/etc. commands.
This code is needed because each context has a different definition
of what is "malicious" content in the middle of a request.
That's why you can use RAW mode and filter the data when necessary.
Compared to this, the run-time overhead of maintaining and testing
taint bits in PHP is miniscule, if my experiences with the prototype
are meaningful.
I am highly skeptical regarding this claim.
- Each ZVAL is marked tainted or not tainted (i.e. we don't taint
individual characters within substrings). Black and white is all.
In some future, someone may want to explore the possibility of
more than two shades. But not now.
That means an additional element to a struct that has thousands of
instances in most scripts, this will be the first overhead caused by
the memory footprint increase.
- Primitives and functions such as echo, eval, or mysql_query are
not allowed to receive tainted input. When this happens the script
terminates with a run-time error. It is a bad idea for software
to continue after a security violation.
You would need to go through some 5,000+ functions that PHP offers
and determine which one can and cannot receive tainted data,
something that virtually guarantees things will be missed, bring us
back to the safe_mode/open_basedir problem.
- PHP propagates taintedness across expressions. If an input to
an expression is tainted, then the result of that expression is
tainted too. There are exceptions to this rule: these are called
sanitisers, as discussed next.
That goes counter to your original point that extensions do not need
to be taint aware, what you propose would require adjustment of
nearly every single extension. The additional tainted, not-tainted
checks will add further overhead.
- The PHP application programmer untaints data by explicit assignment
with an untainted value. For example, the result from
htmlentities()
or mysql_real_escape_string() is not tainted. People could apply
the wrong sanitizer if they really want to. Remember, the purpose
is to help programmers by telling what data needs cleansing. It
is up to them to make the right decision. If we wanted to force
the use of the "right" sanitizer then we would need multiple
shades of untaintedness. This would not be practical.
Again, many functions have different behaviors etc... Let's take an
example htmlspecialchars() is great against XSS but does nothing for
exec(), so if you htmlspecialchars a string then pass it to exec, it
thinks that the data is non-tainted and executes it resulting in
command injection.
Overall, as it stands I do not believe that this is a good idea and
as is my vote would be -0.5 on its inclusion into PHP.
Ilia Alshanetsky
Sounds awefuly like yet another safe_mode, something that proclaims
security, yet being unable to provide it.
Repeating my comments on that, I think that it can be done not like
safe_mode, if we take different approach. Namely, not "mark unsafe,
accept otherwise" but "mark safe, deny otherwise". Meaning, first we
separate functions into 3 categories:
- Cleaners - can take tainted data, produce untainted data
- Regulars - can take tainted data, produce tainted data
- Protected - can take only untainted data
Then we mark all "unknown" function protected, then - the hard part, lot
of work alert - go over code base and extensions and put "regular" flags
on some basic functions (like string manipulation) and "cleaner" flag on
some like filters. This can be done on engine level - meaning, except
some special cases, most function would never need any code change but a
bit in function table description. My opinion is that besides cleaners,
most functions actually would be fine never receiving tainted data
without prior cleaning.
Of course, it would break a lot of code, but it would be also a powerful
way to drive people to write more secure code. E.g. if your app passes
taint-check before deployment, it means most probably you didn't make
the top 80% of PHP security mistakes. Of course, it won't be bulletproof
- but no security enhancement is, and ensuring 100% secure code with
automatic tools is quite a dream anyway.
Unlikely to ever be the case, the overhead of taint modes is generally
quite significant.
This is important consideration. However, if one works with it as
pre-deployment test step and not production, it might be less important
- especially if combined with some kind of unit-testing and coverage
solution.
This of course can be - and should be - combined with runtime solution
like filtering. It is my impression that some view tainting as something
opposed to filtering, while the correct approach would be that tainting
complements filtering, ensuring that no data route left uncovered.
You would need to go through some 5,000+ functions that PHP offers and
determine which one can and cannot receive tainted data, something that
virtually guarantees things will be missed, bring us back to the
safe_mode/open_basedir problem.
That's why - see above - I would recommend reverse approach.
Again, many functions have different behaviors etc... Let's take an
examplehtmlspecialchars()is great against XSS but does nothing for
exec(), so if you htmlspecialchars a string then pass it to exec, it
thinks that the data is non-tainted and executes it resulting in command
injection.
Yep, this is a problem, thus I'm not sure htmlspecialchars should be
always given cleaner attribute. There are a number of ways to deal with it:
- Let the user be smart - if he thought using htmlspecialchars he
probably is aware of filtering, so we hope he can do it right. Most of
problems are due to lack of any filtering at all because nobody even
thought of doing it. - Let the user to say us the function is really cleaning - e.g. add
some parameter that would say "untaint" - suppsing that if one bothered
to put this parameter one probably gave some thought to it. - Let the user use specific cleaner functions - like filters - so that
we reasonably sure he knows what he's doing.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Sounds awefuly like yet another safe_mode, something that
proclaims security, yet being unable to provide it.Repeating my comments on that, I think that it can be done not like
safe_mode, if we take different approach. Namely, not "mark unsafe,
accept otherwise" but "mark safe, deny otherwise".
Ok this is better, but it will break every single application out
there. I for one think that this is unacceptable.
Meaning, first we separate functions into 3 categories:
- Cleaners - can take tainted data, produce untainted data
- Regulars - can take tainted data, produce tainted data
- Protected - can take only untainted data
Then we mark all "unknown" function protected, then - the hard
part, lot of work alert - go over code base and extensions and put
"regular" flags on some basic functions (like string manipulation)
and "cleaner" flag on some like filters. This can be done on engine
level - meaning, except some special cases, most function would
never need any code change but a bit in function table description.
My opinion is that besides cleaners, most functions actually would
be fine never receiving tainted data without prior cleaning.Of course, it would break a lot of code, but it would be also a
powerful way to drive people to write more secure code. E.g. if
your app passes taint-check before deployment, it means most
probably you didn't make the top 80% of PHP security mistakes. Of
course, it won't be bulletproof - but no security enhancement is,
and ensuring 100% secure code with automatic tools is quite a dream
anyway.
When it comes to security things like "most probably" and "likely"
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.
You would need to go through some 5,000+ functions that PHP offers
and determine which one can and cannot receive tainted data,
something that virtually guarantees things will be missed, bring
us back to the safe_mode/open_basedir problem.That's why - see above - I would recommend reverse approach.
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.
Again, many functions have different behaviors etc... Let's take
an examplehtmlspecialchars()is great against XSS but does
nothing forexec(), so if you htmlspecialchars a string then pass
it to exec, it thinks that the data is non-tainted and executes it
resulting in command injection.Yep, this is a problem, thus I'm not sure htmlspecialchars should
be always given cleaner attribute. There are a number of ways to
deal with it:
- Let the user be smart - if he thought using htmlspecialchars he
probably is aware of filtering, so we hope he can do it right. Most
of problems are due to lack of any filtering at all because nobody
even thought of doing it.- Let the user to say us the function is really cleaning - e.g.
add some parameter that would say "untaint" - suppsing that if one
bothered to put this parameter one probably gave some thought to it.- Let the user use specific cleaner functions - like filters - so
that we reasonably sure he knows what he's doing.
I think we should ensure that we can provide users with reliable
means to validate data via things like filter and database escaping
functions 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.
Ilia Alshanetsky
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 :)
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.
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. :)
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.
I think we should ensure that we can provide users with reliable means
to validate data via things like filter and database escaping functions
I agree.
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.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
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
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
Security is benefit. Of course, the developers that are sure they write
secure code anyway need not be bothered by tainting and can leave it off
forever.
The job of a language is to provide tools, not arbitrary crippling
limitation under the guise of security improvement.
I agree. Tainting is one of such tools, aimed at improving security.
safe_mode sounded like a really reasonable idea too, I would've hoped
some lessons from past mistakes could be made.
I do not see what exactly you propose to learn from safe mode mistakes -
that we should never try to improve PHP security by providing language
level tools? I do not see how this can be derived from whatever was
wrong with safe mode. It may be that the tainting would not catch but I
do not think safe mode problems should prevent us from even trying.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
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/addSecurity is benefit. Of course, the developers that are sure they
write secure code anyway need not be bothered by tainting and can
leave it off forever.
So you claim that without taint mode it is not possible to write safe
PHP code?
The job of a language is to provide tools, not arbitrary crippling
limitation under the guise of security improvement.I agree. Tainting is one of such tools, aimed at improving security.
Tainting is a false security it makes you feel secure, when you
aren't. First its off in production and that's where all the hacks
appear, it will have holes due to unforeseen function usage, dynamic
variables, false untainting etc...
safe_mode sounded like a really reasonable idea too, I would've
hoped some lessons from past mistakes could be made.I do not see what exactly you propose to learn from safe mode
mistakes - that we should never try to improve PHP security by
providing language level tools? I do not see how this can be
derived from whatever was wrong with safe mode. It may be that the
tainting would not catch but I do not think safe mode problems
should prevent us from even trying.
Good luck, I suppose on a base level it is entertaining seeing
someone bang their head against the wall time and time again.
Ilia Alshanetsky
So you claim that without taint mode it is not possible to write safe
PHP code?
Actually, I said exactly the opposite - if you write secure code, you do
not need it. If you are concerned about your code potentially being
buggy and do not want to rely only on your own smarts to avoid it - you
need security tools. Tainting is one of such tools.
Tainting is a false security it makes you feel secure, when you aren't.
Well, everything is false security then, because I know of no remotely
accessible system that didn't have one or other way to circumvent the
access control. Programs have bugs, passwords can be stolen or guessed,
etc. So I would propose to move away from generic statements to
something more concrete.
First its off in production and that's where all the hacks appear, it
will have holes due to unforeseen function usage, dynamic variables,
false untainting etc...
You are saying tainting is no silver bullet? I couldn't agree more. But
then again, nothing is :)
Good luck, I suppose on a base level it is entertaining seeing someone
bang their head against the wall time and time again.
You could enjoy the entertainment or you could bring some tools and help
bring the wall down :) Whatever you heart desires.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
So you claim that without taint mode it is not possible to write
safe PHP code?Actually, I said exactly the opposite - if you write secure code,
you do not need it. If you are concerned about your code
potentially being buggy and do not want to rely only on your own
smarts to avoid it - you need security tools. Tainting is one of
such tools.Tainting is a false security it makes you feel secure, when you
aren't.Well, everything is false security then, because I know of no
remotely accessible system that didn't have one or other way to
circumvent the access control. Programs have bugs, passwords can be
stolen or guessed, etc. So I would propose to move away from
generic statements to something more concrete.
Not quite. If you have a function that let's say designed
specifically to take unsafe data and make it safe for a particular
use. For example htmlentities(value, ENT_QUOTES) will make input data
safe to print on screen without concerns about XSS. At the this
limited and very simple level it is very simple to provide user with
convenient and simple means of auditing the data and making it safe.
Tainting as such is not a tool, because it does not secure data, it
just imposes arbitrary limits on what's safe or not, which is only
sometimes right, because you cannot predict every (even every common)
code path. If we take tools like coverity and alike there is a reason
why majority of the thing they find are false positives. The problem
with so many false positives is that they reduce the value of the
tool and make users ignore it or work to simply bypass it.
Consider E_NOTICE, it is a superb tool for finding out things like un-
declared variables (which often cause all manner of exploits), and
yet most developers keep it off because it gets in a way, even though
it has 0 false positives. However I suppose it is simpler and
ultimately harmless to do $value = (int)$_POST['value']; without
checking if $_POST['value'] exists via isset.
Another interesting example I want to bring to your attention is a
seemingly innocuous function strlen(), which you've mentioned before.
Suppose strlen() is said to allow tainted input, since afterall
what's the harm. One simple exploit leading to information disclosure
is to pass it an array() causing the function to generate an error
exposing the script's path.
Good luck, I suppose on a base level it is entertaining seeing
someone bang their head against the wall time and time again.You could enjoy the entertainment or you could bring some tools and
help bring the wall down :) Whatever you heart desires.
Standing next to a wall and trying to knock down its foundations is a
rather dangerous endeavor :)
Ilia Alshanetsky
the harm. One simple exploit leading to information disclosure is to
pass it an array() causing the function to generate an error exposing
the script's path.
You mean when running with display_errors = on? Ouch.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
the harm. One simple exploit leading to information disclosure is
to pass it an array() causing the function to generate an error
exposing the script's path.You mean when running with display_errors = on? Ouch.
Something that most servers do (almost 80% by recent stats).
http://www.nexen.net/images/stories/phpinfos/display_errors.png
Ilia Alshanetsky
Something that most servers do (almost 80% by recent stats).
http://www.nexen.net/images/stories/phpinfos/display_errors.png
You mean "most of the servers that allow strangers to read their
phpinfo()"? I'm not surprised. You think if they expose their phpinfo
you can make it worse by seeing script path in error message?
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Something that most servers do (almost 80% by recent stats).
http://www.nexen.net/images/stories/phpinfos/display_errors.pngYou mean "most of the servers that allow strangers to read their
phpinfo()"? I'm not surprised. You think if they expose their
phpinfo you can make it worse by seeing script path in error message?
It is not just the phpinfo() servers, it is very much a common case I
assure you.
Ilia Alshanetsky
It is not just the
phpinfo()servers, it is very much a common case I
assure you.
Well, people leaving such things in their servers should deal with it
first, then get to talk about real security :) No solution can help a
person who deliberately configures his server wide open. We are talking
about people that try to do it secure and we may help them. For those
who even doesn't try, well...
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
It is not just the
phpinfo()servers, it is very much a common
case I assure you.Well, people leaving such things in their servers should deal with
it first, then get to talk about real security :)
You seem to be ignoring the argument and clinging to a false
assumption that only people with open phpinfo()s have disable_errors
enabled. I guarantee you that is not the case for the most part.
No solution can help a person who deliberately configures his
server wide open.
Accidentally leaving phpinfo(), is wide open? I suppose if I were to
demonstrate a vulnerability on zend.com it would imply Zend does not
care about security?
We are talking about people that try to do it secure and we may
help them.
You're not helping them, just making assumptions about how their code
should work and making them adhere to them.
Ilia Alshanetsky
You seem to be ignoring the argument and clinging to a false assumption
that only people with openphpinfo()s have disable_errors enabled. I
guarantee you that is not the case for the most part.
Well, there's little we can do in that part except for educating users
and changing defaults. The problem is not unique to PHP of course - I
have seen JSP and ASP error messages on most sensitive sites with paths
etc. so many times. But that's entirely unrelated problem.
No solution can help a person who deliberately configures his server
wide open.Accidentally leaving
phpinfo(), is wide open? I suppose if I were to
If you consider exposing script file name a problem, on that scale
having phpinfo() available to google is wide open indeed.
demonstrate a vulnerability on zend.com it would imply Zend does not
care about security?
If you know of vulnerability on zend.com, please write to
webmaster@zend.com, that would be only responsible course of action.
However, I do not see how having vulnerabilities imply not caring for
security.
You're not helping them, just making assumptions about how their code
should work and making them adhere to them.
Yes, and this is helping. Every language does that. Saying "you can't
make 100% work exactly as I wanted without any effort, so entire thing
isn't even worth discussing" is a road nowhere. There's a lot of places
it would be helpful, and there's a lot of places it won't - and that's ok.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
If you know of vulnerability on zend.com, please write to
webmaster@zend.com, that would be only responsible course of
action. However, I do not see how having vulnerabilities imply not
caring for security.
That's my point (and for record previous exploits in the Zend site
were reported several times) just because a mistake was made does not
mean you don't care about security. Same logic must apply to phpinfo
(), someone created it for debugging and forgot to remove and the
search engine stumbled across it. It happens.
You're not helping them, just making assumptions about how their
code should work and making them adhere to them.Yes, and this is helping. Every language does that. Saying "you
can't make 100% work exactly as I wanted without any effort, so
entire thing isn't even worth discussing" is a road nowhere.
There's a lot of places it would be helpful, and there's a lot of
places it won't - and that's ok.
I am saying that you should not try to outsmart the developer because
you assume you know best.
Ilia Alshanetsky
someone created it for debugging and forgot to remove and the search
engine stumbled across it. It happens.
OK, I was overreaching. But main point stays - problems of configuration
are rarely solvable by automatic means, rather by education and choosing
better defaults. If you run site in debug configuration, there's little
we can do - debug configuration is supposed to reveal information.
However, there's a bunch we could do about errors of omission - e.g.
people just not doing stuff which they should do because they forget or
didn't check their code thorough enough.
That is as if we had switch that says "production mode" which could
filter out all info that could be potentially dangerous, etc. - it would
help such phpinfo() people, if we solve chicken and egg problem of
having them to actually turn the switch on :) BTW, may be an idea to
think about too :)
I am saying that you should not try to outsmart the developer because
you assume you know best.
Well, if you don't take me personally - I certainly don't - but
collective judgment of the PHP group - that to some measure that is the
way, we try to guess what developers need and steer the language
accordingly. There's no way of not doing it - you always make choices to
do or not to do certain feature and how to do it.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
At 23:40 16/12/2006, Ilia Alshanetsky wrote:
You're not helping them, just making assumptions about how their
code should work and making them adhere to them.Yes, and this is helping. Every language does that. Saying "you
can't make 100% work exactly as I wanted without any effort, so
entire thing isn't even worth discussing" is a road nowhere.
There's a lot of places it would be helpful, and there's a lot of
places it won't - and that's ok.I am saying that you should not try to outsmart the developer because
you assume you know best.
Ilia,
Why are we outsmarting developers? Security bugs are out there, in
fact in web apps they're pretty much a plague (irregardless of the
language). Does it mean that some developers aren't smart and many
are not properly informed? Absolutely YES - that's the world we live
in... Given that, and the likelihood it'd only get worse (more and
more people are programming the web with less and less training) -
whatever we can provide in the direction of creating better apps can help.
My 2c on this piece is that tainting can be a nice helper tool to
reduce the likelihood of security problems in your code. Nothing
more and nothing less.
I too fear the possibility of tainting becoming the new
safe_mode. "Outsource your security to PHP, it'll take care of
it". But I think there's a way of both designing and pitching
tainting so that we avoid this false perception. If we pitch
tainting as a development-time only tool the points out a certain
class of security mistakes, and is by no means an invisible magnetic
shield that actually protects you from them - then I think it can be
quite useful.
As such, I would consider:
- Saying tainting should not be enabled in production (avoid the
false sense of security people might have if they turn on tainting in
production). - Not necessarily the fastest possible implementation, since it'd be
used for development purposes only. - Consider making this a compile time option with significant
overhead and a big DO NOT ENABLE IN PRODUCTION, so that people have
an even clearer idea they shouldn't rely on it to find their bugs,
and that in fact it's just a helper tool, not unlike a strong IDE.
We could possibly even come up with a new name other than tainting so
that there is not prior perception as to what this feature is
supposed or not supposed to do.
Zeev
Zeev Suraski wrote:
As such, I would consider:
- Saying tainting should not be enabled in production (avoid the false
sense of security people might have if they turn on tainting in
production).- Not necessarily the fastest possible implementation, since it'd be
used for development purposes only.- Consider making this a compile time option with significant overhead
and a big DO NOT ENABLE IN PRODUCTION, so that people have an even
clearer idea they shouldn't rely on it to find their bugs, and that in
fact it's just a helper tool, not unlike a strong IDE.We could possibly even come up with a new name other than tainting so
that there is not prior perception as to what this feature is supposed
or not supposed to do.
Now that puts my own concern into the right light!
IPS's should never be running it?
--
Lester Caine - G8HFL
L.S.Caine Electronic Services - http://home.lsces.co.uk
Model Engineers Digital Workshop -
http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Treasurer - Firebird Foundation Inc. - http://www.firebirdsql.org/index.php
At 23:40 16/12/2006, Ilia Alshanetsky wrote:
You're not helping them, just making assumptions about how their
code should work and making them adhere to them.Yes, and this is helping. Every language does that. Saying "you
can't make 100% work exactly as I wanted without any effort, so
entire thing isn't even worth discussing" is a road nowhere.
There's a lot of places it would be helpful, and there's a lot of
places it won't - and that's ok.I am saying that you should not try to outsmart the developer because
you assume you know best.Ilia,
Why are we outsmarting developers? Security bugs are out there, in
fact in web apps they're pretty much a plague (irregardless of the
language). Does it mean that some developers aren't smart and many
are not properly informed? Absolutely YES - that's the world we live
in... Given that, and the likelihood it'd only get worse (more and
more people are programming the web with less and less training) -
whatever we can provide in the direction of creating better apps can help.My 2c on this piece is that tainting can be a nice helper tool to
reduce the likelihood of security problems in your code. Nothing
more and nothing less.I too fear the possibility of tainting becoming the new
safe_mode. "Outsource your security to PHP, it'll take care of
it". But I think there's a way of both designing and pitching
tainting so that we avoid this false perception. If we pitch
tainting as a development-time only tool the points out a certain
class of security mistakes, and is by no means an invisible magnetic
shield that actually protects you from them - then I think it can be
quite useful.As such, I would consider:
- Saying tainting should not be enabled in production (avoid the
false sense of security people might have if they turn on tainting in
production).- Not necessarily the fastest possible implementation, since it'd be
used for development purposes only.- Consider making this a compile time option with significant
overhead and a big DO NOT ENABLE IN PRODUCTION, so that people have
an even clearer idea they shouldn't rely on it to find their bugs,
and that in fact it's just a helper tool, not unlike a strong IDE.
Ummm, wouldn't it be nice to have the option without taking a great big
artificial overhead penalty for having it enabled? I mean, I for one,
and definitely you for two, cannot possibly expect to catch every single
logic path in an application, and as we've already determined a simple
generic untaint is going to be pointless. It would be best to untaint as
close to the usage of the data as possible. Thus I think E_TAINT or
something being generated in a production environment is perfectly
acceptable in the same sense that E_NOTICE is.
We could possibly even come up with a new name other than tainting so
that there is not prior perception as to what this feature is
supposed or not supposed to do.
blighting :)
<?php
exec( $_GET['foo'] );
?>
A blight is upon you in /path/to/source/foo.php on line 1
Cheers,
Rob.
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
the way I see it there is one simple way of making sure 'taintmode'
doesn't become another magic suicide bullet (ala safemode)...
make taintmode do nothing more than produce warnings/errors/whatever -
don't let it have any effect on the actual running of the application.
I for one would be more than satisfied if taintmode did nothing more than
fill my errorlog with info about how I can make my code better - rather akin
to E_STRICT.
my suggestion (for what it is worth) would be to offer taintmode as an
error_reporting level rather than a switch that effects the actual running
of code, ergo E_TAINT :-) [it should not be part of E_ALL, again akin to E_STRICT]
which ISP would turn on E_TAINT as a security feature given that it would be
logical to document suchlike as being purely a reporting level and having no
effect on actual code run (in exactly the way E_STRICT might fill my logs on a production
machine if I turned it on but has no effect on what my code actually does
[assuming display_errors is Off])
my rationale is that one will have to read the error messages to make any use of
taintmode - and if your going to have to read the error messages anyway why bother
to integrate taintmode into php's behaviour? a developer reacts to the error message not
so much the fact that php halts (because we can turn off taintmode to make the halting go away)
rgds,
Jochem
Zeev Suraski wrote:
At 23:40 16/12/2006, Ilia Alshanetsky wrote:
You're not helping them, just making assumptions about how their
code should work and making them adhere to them.Yes, and this is helping. Every language does that. Saying "you
can't make 100% work exactly as I wanted without any effort, so
entire thing isn't even worth discussing" is a road nowhere.
There's a lot of places it would be helpful, and there's a lot of
places it won't - and that's ok.I am saying that you should not try to outsmart the developer because
you assume you know best.Ilia,
Why are we outsmarting developers? Security bugs are out there, in fact
in web apps they're pretty much a plague (irregardless of the
language). Does it mean that some developers aren't smart and many are
not properly informed? Absolutely YES - that's the world we live in...
Given that, and the likelihood it'd only get worse (more and more people
are programming the web with less and less training) - whatever we can
provide in the direction of creating better apps can help.My 2c on this piece is that tainting can be a nice helper tool to reduce
the likelihood of security problems in your code. Nothing more and
nothing less.I too fear the possibility of tainting becoming the new safe_mode.
"Outsource your security to PHP, it'll take care of it". But I think
there's a way of both designing and pitching tainting so that we avoid
this false perception. If we pitch tainting as a development-time only
tool the points out a certain class of security mistakes, and is by no
means an invisible magnetic shield that actually protects you from them
- then I think it can be quite useful.
As such, I would consider:
- Saying tainting should not be enabled in production (avoid the false
sense of security people might have if they turn on tainting in
production).- Not necessarily the fastest possible implementation, since it'd be
used for development purposes only.- Consider making this a compile time option with significant overhead
and a big DO NOT ENABLE IN PRODUCTION, so that people have an even
clearer idea they shouldn't rely on it to find their bugs, and that in
fact it's just a helper tool, not unlike a strong IDE.We could possibly even come up with a new name other than tainting so
that there is not prior perception as to what this feature is supposed
or not supposed to do.Zeev
This one time, at band camp, Zeev Suraski zeev@zend.com wrote:
- Consider making this a compile time option with significant
overhead and a big DO NOT ENABLE IN PRODUCTION, so that people have
an even clearer idea they shouldn't rely on it to find their bugs,
and that in fact it's just a helper tool, not unlike a strong IDE.
Could it possibly wrapped up in the --enable-debug option??
We could possibly even come up with a new name other than tainting so
that there is not prior perception as to what this feature is
supposed or not supposed to do.
Fainting?
K
"Democracy is two wolves and a lamb voting on what to have for lunch.
Liberty is a well-armed lamb contesting the vote."
This one time, at band camp, Zeev Suraski zeev@zend.com wrote:
- Consider making this a compile time option with significant
overhead and a big DO NOT ENABLE IN PRODUCTION, so that people have
an even clearer idea they shouldn't rely on it to find their bugs,
and that in fact it's just a helper tool, not unlike a strong IDE.Could it possibly wrapped up in the --enable-debug option??
We're not debugging the PHP internals are we?
Cheers,
Rob.
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
Not quite. If you have a function that let's say designed
specifically to take unsafe data and make it safe for a particular
use. For example htmlentities(value, ENT_QUOTES) will make input data
safe to print on screen without concerns about XSS. At the this
limited and very simple level it is very simple to provide user with
convenient and simple means of auditing the data and making it safe.
Tainting as such is not a tool, because it does not secure data, it
just imposes arbitrary limits on what's safe or not, which is only
sometimes right, because you cannot predict every (even every common)
code path. If we take tools like coverity and alike there is a reason
why majority of the thing they find are false positives. The problem
with so many false positives is that they reduce the value of the
tool and make users ignore it or work to simply bypass it.
I have a couple of things to say, the first being to reiterate other's
point of view where the tainting feature would be a tool to help
determine locations of suspect code. Obviously it won't make your code
any more safer, but if you enable it and react to the feedback from
warnings/errors then you WILL have more secure code. False positives
suck, and for such cases I would suggest allowing a developer to easily
untaint data that they feel/know in their (preferrably) expert opinion
is clean. For instance:
(untaint)$someVar;
I think it should be a language level construct for optimal speed.
Additionally I think there should be a (taint)$someVar construct also so
that APIs can specifically taint return values that they know should be
tainted but that might have been untainted during whatever processing
they performed.
Consider E_NOTICE, it is a superb tool for finding out things like un-
declared variables (which often cause all manner of exploits), and
yet most developers keep it off because it gets in a way, even though
it has 0 false positives. However I suppose it is simpler and
ultimately harmless to do $value = (int)$_POST['value']; without
checking if $_POST['value'] exists via isset.
I think the tainting system would be a complimentary system to E_NOTICE
and E_WARNING. Both of these are useless if you don't pay attention to
the messages generated. The same would be true of the tainting system.
You don't get anything for free, you need to actively handle such
issues. This brings me to another issue...
Since tainting is about helping the developer to improve the security of
their code I think that it should be configurable for PHP_INI_ALL. This
would send a clear message to hosting companies that this does not make
their PHP installations more secure.
Additionally I think that there should be three possible settings for
such a tainting mode.
tainting = on
tainting = off
tainting = promiscuous
The first two are obvious. The last would essentially work the same as
tainting being enabled with the exception that scripts will work as
though it was turned off but warnings/errors will show up in error log.
This will allow hosting companies to enable it by default without
adversely affecting scripts.
Lastly, is this something that can be turned off at the compile level so
that the checks for tainting being enabled are completely skipped.
Sometimes you just want to eke out the extra speed in a production
environment.
+1 for tainting (from null karma source :)
Cheers,
Rob.
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
Consider E_NOTICE, it is a superb tool for finding out things like un-
declared variables (which often cause all manner of exploits), and
yet most developers keep it off because it gets in a way, even though
it has 0 false positives.
First, a nitpik:
pg_fetch_row() for a long time gave a false positive (imho) about
seeking past the end of the result set.
To this day I type @pg_fetch_row() as a matter of course, even though
I think this maybe got fixed... :-)
REAL CONTENT:
I think that "taint" might be useful to some developers.
Perhaps it would be best to review the proposed changes for
performance effects, and see how much difference it really makes to
add a bit-flag to every zval, and what other effects taint has with it
turned OFF.
The penalties for turning it ON in performance are a non-issue, I
should think.
If Wietse has a working prototype patch to do it, shouldn't we (an
editorial we, there) at least give it a test spin?
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?