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