On Tue, December 19, 2006 4:25 am, Lester Caine wrote:
> PHP5 and look at this topic as part of the PHP6 jump. Alternatively
> taint is a module that has to be installed separately to a standard
> PHP5
> update?
taint mode being PHP6 only and/or being in PECL instead of an .ini
switch that ISPs na
At 19:33 20/12/2006, Tony Bibbs wrote:
As a casual observer of this thread, this was the explanation that
really clarified the prior posts for me.
To give credit where credit's due, it was Wietse's post, not mine!
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
As a casual observer of this thread, this was the explanation that
really clarified the prior posts for me.
I think having option 3 (enforcement mode) would be great, however, if
everybody is tripping up on mis-managing expectations then I'd suggest a
play on semantics by calling it something
On 12/20/06, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
Pierre wrote:
> I do not want the mode 3, for the reasons I explained earlier. I also
>>
>> Actually, I do. Especially if I had some legacy non-filtering
>> application which I wanted to secure. I would prefer to break it hard
>> and then ass
Pierre wrote:
> I do not want the mode 3, for the reasons I explained earlier. I also
>>
>> Actually, I do. Especially if I had some legacy non-filtering
>> application which I wanted to secure. I would prefer to break it hard
>> and then assemble the pieces in the correct way, rather than play
>>
Hello,
On 12/20/06, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> output to browser, output to system (console/whatever else), sql, xml,
> streams, etc... all of them require special attentions.
Hello, safe mode 2.0! :)
Seriously, I do not think tainting is made for that - and we will have a
At 17:35 19/12/2006, Wietse Venema wrote:
Zeev Suraski:
> 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. "Outso
Stanislav Malyshev wrote:
I disagree - you describe scenario where the user chooses to
insufficiently or wrongly sanitize the data, and since tainting can not
protect from it you say tainting is not useful. However, as I already
said, tainting is not supposed to do that. It's like blaming comp
So my conclusion at this point is, that very frequently taint will not
improve the security significantly because any given input will still be
usable in an unfiltered/incorrectly filtered way for at least one
context. As such it just adds code at the very core of php that provides
too little o
Hi,
I assume its not possible to implement this as a PECL extension. As an
extension it would make sense though even in this b&w approach as it
would then truly be an optional tool you can use like a debugger without
cluttering the core.
regards,
Lukas
--
PHP Internals - PHP Runtime Develop
Stanislav Malyshev wrote:
Then I see little need for having in PHP. All it means that developers
now need to write a untaint wrapper around all incoming input to shut
PHP annoyances up. I can guarantee you a tons and tons of code that
No, they need to use recommended ways to work with variabl
Then I see little need for having in PHP. All it means that developers
now need to write a untaint wrapper around all incoming input to shut
PHP annoyances up. I can guarantee you a tons and tons of code that
No, they need to use recommended ways to work with variables - like
filters and othe
Stanislav Malyshev wrote:
>> output to browser, output to system (console/whatever else), sql, xml,
>> streams, etc... all of them require special attentions.
>
> Hello, safe mode 2.0! :)
> Seriously, I do not think tainting is made for that - and we will have a
> ton of trouble trying to describe
On 20-Dec-06, at 12:08 AM, Andi Gutmans wrote:
Static analysis won't work well enough in PHP.
It can get you 70-80% there though, without touching the engine.
Btw, I don't see someone doing that foreach and using untaint() being
different from someone not filtering their input.
People rea
t; Sent: Tuesday, December 19, 2006 8:57 PM
> To: Stanislav Malyshev
> Cc: PHP internals; Wietse Venema
> Subject: Re: [PHP-DEV] Run-time taint support proposal
>
>
> On 19-Dec-06, at 4:21 PM, Stanislav Malyshev wrote:
>
> >> Wrong again, different contexts ha
PM
> To: Stanislav Malyshev
> Cc: PHP internals; Wietse Venema
> Subject: Re: [PHP-DEV] Run-time taint support proposal
>
> Hello,
>
> On 12/20/06, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > > Now, about taint mode, is it possible to leave the input
On 19-Dec-06, at 4:21 PM, Stanislav Malyshev wrote:
Wrong again, different contexts have different validation
criteria, unless you consider that tainting in PHP wont work.
What's safe to print on screen may not be safe to execute or pass
to the database etc...
I do not think the purpose
output to browser, output to system (console/whatever else), sql, xml,
streams, etc... all of them require special attentions.
Hello, safe mode 2.0! :)
Seriously, I do not think tainting is made for that - and we will have a
ton of trouble trying to describe what is "safe for SQL" (is it for
M
On 12/20/06, Wietse Venema <[EMAIL PROTECTED]> wrote:
> Now, about taint mode, is it possible to leave the input filtering for
> a second and explain me what else you like to do? How do you plan to
> manage the contexts? Do you want this horrible mode 3? Or will you
> argue about input filtering
[A quote that I might end up using somewhere]
> > Very well put/explained.
>
> If it was only about the input filtering, you can use (and should)
> ext/filter (filter.default=string with default flag strip low/high).
>
> And more generally since I use filter filter in my projects, I do not
> use
Hello,
On 12/20/06, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Now, about taint mode, is it possible to leave the input filtering for
> a second and explain me what else you like to do? How do you plan to
> manage the contexts? Do you want this horrible mode 3? Or will you
I'm not sure wha
Now, about taint mode, is it possible to leave the input filtering for
a second and explain me what else you like to do? How do you plan to
manage the contexts? Do you want this horrible mode 3? Or will you
I'm not sure what you mean by "contexts". I suppose by "mode 3" you mean
mode in which t
Hello,
On 12/20/06, Alain Williams <[EMAIL PROTECTED]> wrote:
On Tue, Dec 19, 2006 at 01:21:59PM -0800, Stanislav Malyshev wrote:
> >Wrong again, different contexts have different validation criteria,
> >unless you consider that tainting in PHP wont work. What's safe to print
> >on screen may no
On Tue, Dec 19, 2006 at 01:21:59PM -0800, Stanislav Malyshev wrote:
> >Wrong again, different contexts have different validation criteria,
> >unless you consider that tainting in PHP wont work. What's safe to print
> >on screen may not be safe to execute or pass to the database etc...
>
> I do n
Wrong again, different contexts have different validation criteria,
unless you consider that tainting in PHP wont work. What's safe to print
on screen may not be safe to execute or pass to the database etc...
I do not think the purpose of tainting is or should be to take this kind
of decisions
Jeff Moore wrote:
On Dec 19, 2006, at 10:53 AM, Ilia Alshanetsky wrote:
Bottom line is that does not, there are plenty of Perl application
supposedly safe from XSS due to tainting while in reality are
trivially exploitable via XSS due to the fact validation regex which
does the un-tainting o
On Dec 19, 2006, at 10:53 AM, Ilia Alshanetsky wrote:
Bottom line is that does not, there are plenty of Perl application
supposedly safe from XSS due to tainting while in reality are
trivially exploitable via XSS due to the fact validation regex which
does the un-tainting of data is sub-par.
On Tue, Dec 19, 2006 at 06:05:25PM +0100, Lukas Kahwe Smith wrote:
> Alain Williams wrote:
>
>
> >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.
>
> A non context aware taint
Ilia Alshanetsky wrote:
Wrong again, different contexts have different validation criteria,
unless you consider that tainting in PHP wont work. What's safe to print
on screen may not be safe to execute or pass to the database etc...
Ilia is right here, this is the key concern with this propos
Alain Williams wrote:
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.
A non context aware taint will fail in the majority of use cases.
regards,
Lukas
--
PHP Internals - PHP Runtim
Ilia Alshanetsky wrote:
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.
Most users drive like maniacs anyway, and it will ever be so. Taint mode
cannot save people from them
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 wil
Hello,
On 12/19/06, Robert Cummings <[EMAIL PROTECTED]> wrote:
On Tue, 2006-12-19 at 17:35 +0100, Pierre wrote:
> Hello,
>
> On 12/19/06, Wietse Venema <[EMAIL PROTECTED]> wrote:
> > Zeev Suraski:
>
> > Following up on an earlier suggestion in this thread, I could see
> > at least three modes of
On Tue, 2006-12-19 at 17:35 +0100, Pierre wrote:
> Hello,
>
> On 12/19/06, Wietse Venema <[EMAIL PROTECTED]> wrote:
> > Zeev Suraski:
>
> > Following up on an earlier suggestion in this thread, I could see
> > at least three modes of operation:
> >
> > 1) Disabled. The default setting.
> >
> >
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
Hello,
On 12/19/06, Wietse Venema <[EMAIL PROTECTED]> wrote:
Zeev Suraski:
Following up on an earlier suggestion in this thread, I could see
at least three modes of operation:
1) Disabled. The default setting.
2) Audit mode. Report perceived problems to logfile. This can be
used by de
On Tue, 2006-12-19 at 11:18 -0500, Ilia Alshanetsky wrote:
> >
> > Let us be done with this discussion and agree (as the Perl & Ruby
> > people have)
> > that it is best to have a useful tool even if we can't make it 100%
> > perfect.
>
> So you propose to give a partially working tool that pr
Ilia Alshanetsky wrote:
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
Nobody at all in this discussion has suggested taint promises data
security. Nobody has said it promises anything. But an imper
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 w
On Tue, Dec 19, 2006 at 10:53:51AM -0500, Ilia Alshanetsky wrote:
>
> On 19-Dec-06, at 10:35 AM, Wietse Venema wrote:
> ...
> Bottom line is that does not, there are plenty of Perl application
> supposedly safe from XSS due to tainting while in reality are
> trivially exploitable via XSS due
On 19-Dec-06, at 10:35 AM, Wietse Venema wrote:
As for positioning the feature, I don't think the problem is with
the name "taint" itself. It was introduced under this name with
Perl3 in 1989(*), and later under the same name in Ruby and other
programming languages. I am not aware that shortco
Zeev Suraski:
> 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 ca
On Wed, 2006-12-20 at 01:33 +1100, Kevin Waterson wrote:
> This one time, at band camp, Zeev Suraski <[EMAIL PROTECTED]> wrote:
>
>
>
> > - 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 id
This one time, at band camp, Zeev Suraski <[EMAIL PROTECTED]> wrote:
> - 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
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 t
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
Tom Sommer wrote:
Ignoring the fact that this is somewhat off-topic, why would ISPs use the
Lite version as opposed to the "bloated" version? Their users want
features, functions, they want PHP - why settle for the lesser version?
If you don't want taint support, because you feel it's bloat, do
-
Zeev Suraski wrote:
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
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 t
On Tue, December 19, 2006 09:29, Lester Caine wrote:
> Robert Cummings wrote:
>
>> On Tue, 2006-12-19 at 04:54 +, Lester Caine wrote:
>>
>>> Richard Lynch wrote:
>>>
On Sat, December 16, 2006 7:03 am, Lester Caine wrote:
> Of cause many of us never go near the raw database calls a
On Tue, 2006-12-19 at 08:29 +, Lester Caine wrote:
> Robert Cummings wrote:
> > On Tue, 2006-12-19 at 04:54 +, Lester Caine wrote:
> >> Richard Lynch wrote:
> >>> On Sat, December 16, 2006 7:03 am, Lester Caine wrote:
> Of cause many of us never go near the raw database calls anyway, s
Tom Sommer wrote:
On Tue, December 19, 2006 05:54, Lester Caine wrote:
Richard Lynch wrote:
On Sat, December 16, 2006 7:03 am, Lester Caine wrote:
Of cause many of us never go near the raw database calls anyway,
since we are using frameworks that carry out lot of the security
checks at a gen
Robert Cummings wrote:
On Tue, 2006-12-19 at 04:54 +, Lester Caine wrote:
Richard Lynch wrote:
On Sat, December 16, 2006 7:03 am, Lester Caine wrote:
Of cause many of us never go near the raw database calls anyway, since
we are using frameworks that carry out lot of the security checks at
On Tue, December 19, 2006 05:54, Lester Caine wrote:
> Richard Lynch wrote:
>
>> On Sat, December 16, 2006 7:03 am, Lester Caine wrote:
>>
>>> Of cause many of us never go near the raw database calls anyway,
>>> since we are using frameworks that carry out lot of the security
>>> checks at a generi
On Tue, 2006-12-19 at 04:54 +, Lester Caine wrote:
> Richard Lynch wrote:
> > On Sat, December 16, 2006 7:03 am, Lester Caine wrote:
> >> Of cause many of us never go near the raw database calls anyway, since
> >> we are using frameworks that carry out lot of the security checks at a
> >> gener
Richard Lynch wrote:
On Sat, December 16, 2006 7:03 am, Lester Caine wrote:
Of cause many of us never go near the raw database calls anyway, since
we are using frameworks that carry out lot of the security checks at a
generic level - so I see little point adding more checks at a level
that
major
On Sat, December 16, 2006 7:03 am, Lester Caine wrote:
> Of cause many of us never go near the raw database calls anyway, since
> we are using frameworks that carry out lot of the security checks at a
> generic level - so I see little point adding more checks at a level
> that
> major projects do n
someone created it for debugging and forgot to remove and the search
engine stumbled across it. It happens.
OK, I was overreaching. But main point stays - problems of configuration
are rarely solvable by automatic means, rather by education and choosing
better defaults. If you run site in debu
On 16-Dec-06, at 4:26 PM, Stanislav Malyshev wrote:
If you know of vulnerability on zend.com, please write to
[EMAIL PROTECTED], that would be only responsible course of
action. However, I do not see how having vulnerabilities imply not
caring for security.
That's my point (and for recor
You seem to be ignoring the argument and clinging to a false assumption
that only people with open phpinfo()s have disable_errors enabled. I
guarantee you that is not the case for the most part.
Well, there's little we can do in that part except for educating users
and changing defaults. The
On 15-Dec-06, at 9:32 PM, Stanislav Malyshev wrote:
It is not just the phpinfo() servers, it is very much a common
case I assure you.
Well, people leaving such things in their servers should deal with
it first, then get to talk about real security :)
You seem to be ignoring the argument
(Wietse Venema) wrote:
! zend_uchar is_ref:7;
! zend_uchar taint_flag:1;
Beginning of this year I was actually making tests with something like
that but I used
zend_uchar is_ref:1;
zend_uchar flags:7;
to be able to support multiple taint types (HTML and DB where the
On Sat, 2006-12-16 at 13:03 +, Lester Caine wrote:
> Lukas Kahwe Smith wrote:
>
> > To me some of Ilia's arguements do not make sense. Ext/filter has the
> > same danger of creating a false sense of security. The arguements that
> > did make sense to me are about the issue of (un)tainting be
Lukas Kahwe Smith wrote:
To me some of Ilia's arguements do not make sense. Ext/filter has the
same danger of creating a false sense of security. The arguements that
did make sense to me are about the issue of (un)tainting being directly
tied to the context in which the variable is being used.
Hi,
To me some of Ilia's arguements do not make sense. Ext/filter has the
same danger of creating a false sense of security. The arguements that
did make sense to me are about the issue of (un)tainting being directly
tied to the context in which the variable is being used.
This is a problem
Ilia Alshanetsky wrote:
In theory, you need to consider that many ISPs and users will interpret
taint mode == secure and enable it causing much grief to distributable
application writers who need to accommodate every environment.
actually i dont think this is a valid argument. people will qu
Lester Caine wrote:
I'm sure many people have their own preferred tools for creating files
- all I was trying to say was that - is taint support actually needed
at run time? Something that improves the visibility of mistakes while
editing files seems to be more worthwhile - something that can a
Andi Gutmans wrote:
I don't quite understand the relevance of PHPEclipse to the issue.
And I'm not sure how you judge "clogging up" PHP without seeing a patch
especially as I'm not sure how much PHP internals hacking you've done.
I'm sure many people have their own preferred tools for creating
On Sat, 2006-12-16 at 07:31 +, Lester Caine wrote:
> Wietse Venema wrote:
> > Ilia Alshanetsky:
> >> And here is your first exploit, let's say we say
> >> mysql_real_escape_string() takes tainted data and makes it untainted,
> >> what happens when this "safe" data is passed to exec().
> >
t; From: Lester Caine [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 15, 2006 11:31 PM
> To: PHP internals
> Subject: Re: [PHP-DEV] Run-time taint support proposal
>
> Wietse Venema wrote:
> > Ilia Alshanetsky:
> >> And here is your first exploit, let's say
Wietse Venema wrote:
Ilia Alshanetsky:
And here is your first exploit, let's say we say
mysql_real_escape_string() takes tainted data and makes it untainted,
what happens when this "safe" data is passed to exec().
You need a malicous code writer to have an exploit. As far as I
know, PHP is
2 PM
> To: PHP internals
> Subject: Re: [PHP-DEV] Run-time taint support proposal
>
> Richard Lynch:
> > On Fri, December 15, 2006 4:31 pm, Wietse Venema wrote:
> > > Even if some taint check is to restrictive at some point in time,
> > > the programmer can always o
It is not just the phpinfo() servers, it is very much a common case I
assure you.
Well, people leaving such things in their servers should deal with it
first, then get to talk about real security :) No solution can help a
person who deliberately configures his server wide open. We are talking
On 15-Dec-06, at 7:23 PM, Stanislav Malyshev wrote:
Something that most servers do (almost 80% by recent stats).
http://www.nexen.net/images/stories/phpinfos/display_errors.png
You mean "most of the servers that allow strangers to read their
phpinfo()"? I'm not surprised. You think if the
Richard Lynch:
> On Fri, December 15, 2006 4:31 pm, Wietse Venema wrote:
> > Even if some taint check is to restrictive at some point in time,
> > the programmer can always overcome it with an explicit action.
>
> Would that require some sort of bogus string non-manipulation, or do
> you foresee a
On Fri, December 15, 2006 5:05 pm, Ilia Alshanetsky wrote:
> In theory, you need to consider that many ISPs and users will
> interpret taint mode == secure and enable it causing much grief to
> distributable application writers who need to accommodate every
> environment.
That accommodation consi
ose APIs then that can be done in parallel.
>
> > -Original Message-
> > From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of
> > Ilia Alshanetsky
> > Sent: Friday, December 15, 2006 3:12 PM
> > To: PHP internals
> > Subject: Re: [PHP-DEV] Run-ti
On Fri, December 15, 2006 5:32 pm, Ilia Alshanetsky wrote:
>
> On 15-Dec-06, at 6:21 PM, Andi Gutmans wrote:
>
>> Well you wouldn't have to use tainted mode of course. This can/
>> should be
>> turned off by default.
>
> safe_mode is/was off by default to, and yet a good chunk of hosts
> enabled it
On Fri, December 15, 2006 4:31 pm, Wietse Venema wrote:
> Even if some taint check is to restrictive at some point in time,
> the programmer can always overcome it with an explicit action.
Would that require some sort of bogus string non-manipulation, or do
you foresee a "untaint" function which d
On Fri, December 15, 2006 5:12 pm, Ilia Alshanetsky wrote:
> And here is your first exploit, let's say we say
> mysql_real_escape_string() takes tainted data and makes it untainted,
> what happens when this "safe" data is passed to exec(). You are going
> to need to deal with different levels of ta
On Fri, December 15, 2006 5:43 pm, Ilia Alshanetsky wrote:
> Consider E_NOTICE, it is a superb tool for finding out things like un-
> declared variables (which often cause all manner of exploits), and
> yet most developers keep it off because it gets in a way, even though
> it has 0 false positives
Ilia Alshanetsky:
> And here is your first exploit, let's say we say
> mysql_real_escape_string() takes tainted data and makes it untainted,
> what happens when this "safe" data is passed to exec().
You need a malicous code writer to have an exploit. As far as I
know, PHP is not a platform for
Something that most servers do (almost 80% by recent stats).
http://www.nexen.net/images/stories/phpinfos/display_errors.png
You mean "most of the servers that allow strangers to read their
phpinfo()"? I'm not surprised. You think if they expose their phpinfo
you can make it worse by seeing
On Fri, 2006-12-15 at 18:43 -0500, Ilia Alshanetsky wrote:
> On 15-Dec-06, at 6:27 PM, Stanislav Malyshev wrote:
>
> Not quite. If you have a function that let's say designed
> specifically to take unsafe data and make it safe for a particular
> use. For example htmlentities(value, ENT_QUOTES)
On 15-Dec-06, at 7:01 PM, Stanislav Malyshev wrote:
the harm. One simple exploit leading to information disclosure is
to pass it an array() causing the function to generate an error
exposing the script's path.
You mean when running with display_errors = on? Ouch.
Something that most serv
the harm. One simple exploit leading to information disclosure is to
pass it an array() causing the function to generate an error exposing
the script's path.
You mean when running with display_errors = on? Ouch.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.c
On 15-Dec-06, at 6:40 PM, Alain Williams wrote:
OK: so there may be a few cases where it won't work, that does not
mean
that there won't be great advantages for the majority of situations.
I'd wager there would be more then a few instances, but without code
its kinda hard to demonstrate.
On 15-Dec-06, at 6:28 PM, Stanislav Malyshev wrote:
I'd say you have pretty weird code if you do include $_POST
['VAR']; and yet people do exactly that.
And if we had tainting, people would know it's bad, and would know
why. :)
Bitmask identifying different taint modes.
Can you elabora
(I realize that I haven't got any karma here. Just want to offer a
users point of view. :))
I think this would make a great addition. Just not for educational
purposes, but also to help experienced developers avoid missing holes.
Ilia wrote:
safe_mode is/was off by default to, and yet a good c
On 15-Dec-06, at 6:27 PM, Stanislav Malyshev wrote:
So you claim that without taint mode it is not possible to write
safe PHP code?
Actually, I said exactly the opposite - if you write secure code,
you do not need it. If you are concerned about your code
potentially being buggy and do no
On Fri, Dec 15, 2006 at 06:32:06PM -0500, Ilia Alshanetsky wrote:
> I think people generally follow the path of least resistance and for
> compat purposes I suspect most application will simply create a quick
> wrapper to **untaint** all input data so they can use it within their
> applicati
On 15-Dec-06, at 6:21 PM, Andi Gutmans wrote:
Well you wouldn't have to use tainted mode of course. This can/
should be
turned off by default.
safe_mode is/was off by default to, and yet a good chunk of hosts
enabled it under the assumption it would make their setups secure.
I think havi
I'd say you have pretty weird code if you do include $_POST['VAR']; and
yet people do exactly that.
And if we had tainting, people would know it's bad, and would know why. :)
Bitmask identifying different taint modes.
Can you elaborate which modes do you propose?
--
Stanislav Malyshev, Zend
So you claim that without taint mode it is not possible to write safe
PHP code?
Actually, I said exactly the opposite - if you write secure code, you do
not need it. If you are concerned about your code potentially being
buggy and do not want to rely only on your own smarts to avoid it - you
3:12 PM
> To: PHP internals
> Subject: Re: [PHP-DEV] Run-time taint support proposal
>
>
> On 15-Dec-06, at 6:06 PM, Wietse Venema wrote:
>
> > Ilia Alshanetsky:
> >> On 15-Dec-06, at 5:19 PM, Wietse Venema wrote:
> >>> Ilia Alshanetsky:
> >>&
shanetsky [mailto:[EMAIL PROTECTED] On Behalf Of
> Ilia Alshanetsky
> Sent: Friday, December 15, 2006 3:08 PM
> To: Alain Williams
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Run-time taint support proposal
>
>
> On 15-Dec-06, at 6:02 PM, Alain Williams wrote:
>
>
On 15-Dec-06, at 6:18 PM, Stanislav Malyshev wrote:
And here is your first exploit, let's say we say
mysql_real_escape_string() takes tainted data and makes it
untainted, what happens when this "safe" data is passed to exec().
You are going to
I'd say you have really weird code if you do
On 15-Dec-06, at 6:14 PM, Stanislav Malyshev wrote:
That's exactly it, PHP is popular because it is easy to use. You
take that away and quite frankly there is very little reason to
left to use PHP over C#, Python, etc...
Well, this is old :) Discussing every feature there are people that
And here is your first exploit, let's say we say
mysql_real_escape_string() takes tainted data and makes it untainted,
what happens when this "safe" data is passed to exec(). You are going to
I'd say you have really weird code if you do mysql_real_escape_string()
in order to pass the data to
On 15-Dec-06, at 6:11 PM, Stanislav Malyshev wrote:
All it means is extra work for developers with little or no
tangible benefits. I also wonder how taint will work with the
standard remove/add
Security is benefit. Of course, the developers that are sure they
write secure code anyway nee
1 - 100 of 116 matches
Mail list logo
