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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
