Re: Run-time taint support proposal
| From: | Zeev Suraski | Date: | Tue, 19 Dec 2006 10:08:41 +0000 |
| Subject: | Re: Run-time taint support proposal | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-27091@lists.php.net to get a copy of this message | ||
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. ZeevI am saying that you should not try to outsmart the developer because you assume you know best.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.