Re: Run-time taint support proposal

On 19-Dec-06, at 11:36 AM, Alain Williams wrote:

On Tue, Dec 19, 2006 at 11:18:02AM -0500, Ilia Alshanetsky wrote:

On 19-Dec-06, at 11:06 AM, Alain Williams wrote:

It is quite true that a taint flag cannot *guarantee* to make a PHP script completely safe. Using a regex to untaint a value will not guarantee that you end up with a perfectly safe value -- partly because it depends on what you want to do with it.

Regex is the approach used by Perl to un-taint data, which is why I chose to mention it. The problem I am trying to show you that you seem to be stead-fast ignoring is that php variables are often used in different contexts within the scope of the same script. There are

Can happen in Perl/... as well.

I know that, which means the taint mode in Perl is woefully inadequate solution that offers very little security. So, why try to reproduce the bad idea in PHP as well? Isn't the idea to borrow the best features and learn from other people's mistakes?

safe against SQL injection (not really though, due to charset tricks with MySQL) it will definitely not be safe against XSS. It is my opinion is that a false sense of security is far worse then knowing your code may potentially have security holes.

I wear a seat belt when I drive my car because it will help me in many small accidents. I do not leave it off because it will be useless if a large truck decides to run me down.

To use your car analogy and safe_mode history, most users will start driving like maniacs, violating every traffic law thinking that the seat belt makes them invincible.

So you propose to give a partially working tool that promises data security and then expect people not to rely on it 100% because it is easy to

I propose to give a partially working tool that helps in the majority of cases. I am aware that it will not be a panacea but that it is preferable to nothing.

Ilia Alshanetsky