Re: Run-time taint support proposal

On Tue, 2006-12-19 at 12:08 +0200, 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. 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. | `------------------------------------------------------------'