# Run-time taint support proposal - Thread: https://externals.io/message/26979 - Original archive: https://news-web.php.net/php.internals/26979 - Started by Wietse Venema on 2006-12-15T20:14:48+00:00 - Messages: 27 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/26979.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #26979 — Wietse Venema — 2006-12-15T20:14:48+00:00 URL: https://externals.io/message/26979#26979 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 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. 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. --- ## #26980 — Ilia Alshanetsky — 2006-12-15T20:43:23+00:00 URL: https://externals.io/message/26979#26980 · In reply to: #26979 > 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 --- ## #26981 — Stanislav Malyshev — 2006-12-15T21:16:00+00:00 URL: https://externals.io/message/26979#26981 · In reply to: #26980 > 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: 1. Cleaners - can take tainted data, produce untainted data 2. Regulars - can take tainted data, produce tainted data 3. 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 > 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. 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: 1. 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. 2. 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. 3. 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/ --- ## #26982 — Ilia Alshanetsky — 2006-12-15T21:43:29+00:00 URL: https://externals.io/message/26979#26982 · In reply to: #26981 > > […] > > 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: > 1. Cleaners - can take tainted data, produce untainted data > 2. Regulars - can take tainted data, produce tainted data > 3. 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. > > […] > > 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. > > > […] > > 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: > 1. 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. > 2. 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. > 3. 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 --- ## #26983 — Stanislav Malyshev — 2006-12-15T21:58:31+00:00 URL: https://externals.io/message/26979#26983 · In reply to: #26982 > 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/ --- ## #26988 — Ilia Alshanetsky — 2006-12-15T23:02:27+00:00 URL: https://externals.io/message/26979#26988 · In reply to: #26983 > > […] > > 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. > > […] > > 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. > > […] > > 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. > > […] > > 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 --- ## #26993 — Stanislav Malyshev — 2006-12-15T23:11:23+00:00 URL: https://externals.io/message/26979#26993 · In reply to: #26988 > 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/ --- ## #26996 — Ilia Alshanetsky — 2006-12-15T23:17:16+00:00 URL: https://externals.io/message/26979#26996 · In reply to: #26993 > > […] > > 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. So you claim that without taint mode it is not possible to write safe PHP code? > > > […] > > 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... > > […] > > 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 --- ## #27002 — Stanislav Malyshev — 2006-12-15T23:27:45+00:00 URL: https://externals.io/message/26979#27002 · In reply to: #26996 > 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/ --- ## #27006 — Ilia Alshanetsky — 2006-12-15T23:43:54+00:00 URL: https://externals.io/message/26979#27006 · In reply to: #27002 > > […] > > 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. > > > […] > > 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. > > […] > > 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 --- ## #27010 — Stanislav Malyshev — 2006-12-16T00:01:32+00:00 URL: https://externals.io/message/26979#27010 · In reply to: #27006 > 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/ --- ## #27011 — Ilia Alshanetsky — 2006-12-16T00:04:10+00:00 URL: https://externals.io/message/26979#27011 · In reply to: #27010 > > […] > > 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 --- ## #27012 — Robert Cummings — 2006-12-16T00:12:11+00:00 URL: https://externals.io/message/26979#27012 · In reply to: #27006 > > > 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. | `------------------------------------------------------------' --- ## #27014 — Stanislav Malyshev — 2006-12-16T00:23:47+00:00 URL: https://externals.io/message/26979#27014 · In reply to: #27011 > 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/ --- ## #27019 — Richard Lynch — 2006-12-16T01:07:11+00:00 URL: https://externals.io/message/26979#27019 · In reply to: #27006 > 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? --- ## #27030 — Ilia Alshanetsky — 2006-12-16T02:13:02+00:00 URL: https://externals.io/message/26979#27030 · In reply to: #27014 > > > […] > > 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? It is not just the `phpinfo()` servers, it is very much a common case I assure you. Ilia Alshanetsky --- ## #27032 — Stanislav Malyshev — 2006-12-16T02:32:30+00:00 URL: https://externals.io/message/26979#27032 · In reply to: #27030 > 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/ --- ## #27050 — Ilia Alshanetsky — 2006-12-16T20:18:19+00:00 URL: https://externals.io/message/26979#27050 · In reply to: #27032 > > […] > > 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 --- ## #27051 — Stanislav Malyshev — 2006-12-16T21:26:41+00:00 URL: https://externals.io/message/26979#27051 · In reply to: #27050 > 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. 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. > > […] > > 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/ --- ## #27052 — Ilia Alshanetsky — 2006-12-16T21:40:01+00:00 URL: https://externals.io/message/26979#27052 · In reply to: #27051 > 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. > > […] > > 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 --- ## #27058 — Stanislav Malyshev — 2006-12-17T09:24:56+00:00 URL: https://externals.io/message/26979#27058 · In reply to: #27052 > 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/ --- ## #27091 — Zeev Suraski — 2006-12-19T10:08:41+00:00 URL: https://externals.io/message/26979#27091 · In reply to: #27052 At 23:40 16/12/2006, Ilia Alshanetsky wrote: > > […] > >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 --- ## #27092 — Lester Caine — 2006-12-19T10:29:31+00:00 URL: https://externals.io/message/26979#27092 · In reply to: #27091 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 --- ## #27094 — Robert Cummings — 2006-12-19T10:51:11+00:00 URL: https://externals.io/message/26979#27094 · In reply to: #27091 > At 23:40 16/12/2006, Ilia Alshanetsky wrote: > > […] > > 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 :) > > […] 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. | `------------------------------------------------------------' --- ## #27095 — Jochem Maas — 2006-12-19T11:46:43+00:00 URL: https://externals.io/message/26979#27095 · In reply to: #27091 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: > > […] > > 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 --- Next page: https://externals.io/message/26979.md?page=2