Re: Run-time taint support proposal
| From: | Ilia Alshanetsky | Date: | Fri, 15 Dec 2006 23:32:06 +0000 |
| Subject: | Re: Run-time taint support proposal | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-27004@lists.php.net to get a copy of this message | ||
On 15-Dec-06, at 6:21 PM, Andi Gutmans wrote:
Well you wouldn't have to use tainted mode of course. This can/should be turned off by default.safe_mode is/was off by default to, and yet a good chunk of hosts enabled it under the assumption it would make their setups secure.
I think having such a mode would be of great help to many users though. It would allow them to find any quirks in their data/input filtering and help them focus on where they should do a better job.I think people generally follow the path of least resistance and for compat purposes I suspect most application will simply create a quick wrapper to **untaint** all input data so they can use it within their application without worrying about tainting getting in the way.
Of course no one such solution will solve application-level security issues but it could end up being a very useful tool which helps people address the majority of such problems.Tainting may have helped if you are using straight forward data, but what happens when you start doing appending or passing data through string modification operations. I almost guarantee that there will be a series of operations or function calls that if executed in a certain order will mask tainted input making it appear safe. I'd gladly provide you with examples, but there is no sample code, if I have time I'll take a peak at Perl and Ruby that implement tainting and see if a quick taint bypass can be devised.
I've been on the fence here from the beginning. I am pretty sure this would be a very useful feature but I'm somewhat paranoid after the whole safe_mode saga. Stas pointing out the difference between safe_mode which is "trust everyone unless explicitly pointed out" vs. a possible approach here of "trust noone unless explicitly pointed out" might make the difference though.All it means that this breaks every applications and the security benefits are somewhat ambiguous, but in all fairness the full consequences are hard to predict without sample code. Ilia Alshanetsky