Tainted Mode Decision

Nuno Lopes

18 years ago

> I just wanted to ask if there was ever a decision made that said tainted
> mode will go into PHP mainstream.

no, there was no decision yet.

> It is no secret that I don't like the idea of a taint mode in PHP
> because it cannot be made secure and fast at the same time.

/me too. Although I can't argue about those two implementations because I
haven't looked at them yet, I think we shouldn't include neither of them in
the core. At most we could introduce some hooks in the engine to allow these
kind of extensions to be self-contained and distributed by 3rd parties
without much trouble.
Also I don't know how GRASP works, but it's very difficult (if not
impossible) to provide good analysis..

Nuno

Stefan Esser

18 years ago

> Also I don't know how GRASP works, but it's very difficult (if not
> impossible) to provide good analysis..

The difference between GRASP and PHP Taint Mode is that GRASP tracks
taintedness on a byte level
(it really tracks that e.g. byte 4, 7 and 8-20 of a variable are tainted
and the others not) and Venema's
implementation only tracks on a per variable level.

It is therefore obvious that the GRASP way cannot be made fast and that
Venema's implementation will always be faster.

The other difference is that Venema's implementation assumes that
functions exist that make a variable safe for usage in SQL, HTML, ...
When such a function is used the variable is marked as not tainted... In
the previous mail I showed examples why this is not secure.

GRASP on the other hand hooks the SQL/output functions and parses the
SQL query/output and catches tainted bytes in places where they could be
dangerous.
The only problems here are how slow this is and that the parsers need to
be compatible.

Stefan Esser

Nuno Lopes

18 years ago

> The other difference is that Venema's implementation assumes that
> functions exist that make a variable safe for usage in SQL, HTML, ...
> When such a function is used the variable is marked as not tainted... In
> the previous mail I showed examples why this is not secure.
>
> GRASP on the other hand hooks the SQL/output functions and parses the
> SQL query/output and catches tainted bytes in places where they could be
> dangerous.
> The only problems here are how slow this is and that the parsers need to
> be compatible.

BTW, have you already been able to found real-world exploitable bugs with
GRASP?

Nuno

Lukas Kahwe Smith

18 years ago

On 18.11.2007, at 14:00, Stefan Esser wrote:

Hi Stefan,

> It is therefore obvious that the GRASP way cannot be made fast and
> that
> Venema's implementation will always be faster.

I wonder how other languages solve this dilemma? Like how does Ruby's
taint model work? What are the experience there? Are there any other
languages that have a taint model?

regards.
Lukas

Stanislav Malyshev

18 years ago

> I wonder how other languages solve this dilemma? Like how does Ruby's
> taint model work? What are the experience there? Are there any other
> languages that have a taint model?

Perl has. AFAIK it's variable-based.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

Stefan Esser

18 years ago

Hello Lukas,

> I wonder how other languages solve this dilemma? Like how does Ruby's
> taint model work? What are the experience there? Are there any other
> languages that have a taint model?

I don't know exactly what they do, but if I am not completely mistaken
the difference is simple.

AFAIK perl has variable level tainting, but does not have implicit
untainting.

That means the developer has to use something like untaint($variable)
whenever he wants to use tainted input.
This means the developer can only use tainted input when he THINKS and
explicitly untaint()s it. He is
responsible for bad decisions like using the wrong escaping function and
telling perl that he untaint()ed the input.

This is different from the implicit untainting through htmlentities()
and mysql_real_escape_string() because there
are obviously cases where these functions are the WRONG functions and
the developer will never realise this
because he was not taught to untaint() himself only when he is sure...

Stefan Esser

Lukas Kahwe Smith

18 years ago

On 18.11.2007, at 22:56, Stefan Esser wrote:

>
> This is different from the implicit untainting through htmlentities()
> and mysql_real_escape_string() because there
> are obviously cases where these functions are the WRONG functions and
> the developer will never realise this
> because he was not taught to untaint() himself only when he is sure...

Ok, I guess this is a fundamental difference that we should probably
take note if before we make any decision. Should it be a tool that
one can just enable when one cares or should we require that
developers actually code towards the taint model?

I personally think that library developers could be expected to
actually make explicit untaint() calls and bytecode caches could be
made smart enough to strip these out for the people that do not care
about the added security (which one might not need in production).

However for the final glue that needs to be written to put all the
libraries to work, I think its fairly unrealistic. Then again maybe
the people that do care enough (because they are working for a bank)
would still have the necessary time to add all the relevant untaint()
calls. The rest would probably appreciate a tool that helps them
getting closed to that magical 100% secure mark.

regards,
Lukas

Stanislav Malyshev

18 years ago

> AFAIK perl has variable level tainting, but does not have implicit
> untainting.

Applying any regexp to tainted variable produces untainted results in Perl.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

Steph

18 years ago

Hi Stefan,

> I just wanted to ask if there was ever a decision made that said tainted
> mode will go into PHP mainstream.

No decision as such - I believe Wietse is doing his best to find out exactly
how viable it is, no?

> it seems some people want the fast implementation of Wietse in the core
> which would be bad, because it is based on
> wrong assumptions and uses an insecure design that does only give a
> false sense of security.

In a preliminary release for feedback purposes you talk about wrong
assumptions? Surely this is the whole point of having a preliminary release
for feedback :)

> Examples for the wrong assumptions in PHP Taintmode:
> 1) _SERVER['PHP_SELF'] is not safe and allows XSS (and more) in many
> applications
> 2) Using mysql_real_escape_string() on user input does not make it safe
> for SQL. It only makes SQL strings safe.
> Example: "SELECT * FROM table WHERE id=".mysql_real_escape_string($id)
> is NOT secure but will result in no taint warning
> 3) Using htmlentities() on usr input does not make it safe for HTML
> output. It only makes it safe in some situations.
> Example:  echo '....<sometag  style="some-attribute:
> ',htmlentities($user_input),'">'. Will allow XSS through the style
> attribute without a taint warning
> Example2:  echo '....<img src="',htmlentities($user_input),'">'. Will
> allow XSS through javascript: URL (f.e. in Opera) without a taint warning

Now, yes. Since these are all things that 'every fule know', isn't it more
than likely that they'll be addressed before taint mode ever sees the light
of day?

I think it's probably worth giving Wietse as much help as you can at this
stage to make it better, since the thing's fast and since you know where to
find the problem areas better than anyone. That said - I don't know if it's
possible to have an extension/hooks approach without losing speed, but if it
_is_ I'd personally vote for taking that approach.

- Steph

Stefan Esser

18 years ago

Hi Steph,

>
> In a preliminary release for feedback purposes you talk about wrong
> assumptions? Surely this is the whole point of having a preliminary
> release for feedback :)

yes of course it is preliminary. But the whole idea is flawed. It is
assumed that a single function exists that makes user input secure for
HTML or for SQL. But infact there is not.

There exists a wide number of possible contexts like
1) SQL: Inside a SQL string
2) SQL: Inside a SQL table name
3) SQL: Inside a SQL field name (uncommon)
4) SQL: Inside a SQL comment
5) SQL: Where a numerical id is expected
6) ... possible others

All these different contexts need another way of preparation/escaping.
What kind of handling is actually needed can only be found out by
parsing the query and knowing what bytes are tained.
This cannot be done if you only use variable level tainting.

If you look at HTML it gets even more complicated because you have many
more possibilities like
1) HTML: Outside of a TAG
2) HTML: Inside a TAG
3) HTML: Inside an attribut of a style tag
4) HTML: Dangerous URLs in attributes
5) HTML: JavaScript between <script> tags
6) HTML: JavaScript inside a JS String
7) ....

That said the implicit untainting by use of mysql_real_escape_string()
and htmlentities() is simply not feasible.

Stefan Esser

(Wietse Venema)

18 years ago

Stefan Esser:
[ Charset ISO-8859-15 unsupported, converting... ]

> Hi Steph,
>
> >
> > In a preliminary release for feedback purposes you talk about wrong
> > assumptions? Surely this is the whole point of having a preliminary
> > release for feedback :)
> yes of course it is preliminary. But the whole idea is flawed. It is
> assumed that a single function exists that makes user input secure for
> HTML or for SQL. But infact there is not.

In my own code, the htmlentities() conversion function makes data
safe ONLY for HTML but NOT for SHELL, MYSQL*, etc.

Likewise, the mysqli_real_escape_string() conversion function makes
data safe ONLY for MYSQLI but NOT for MYSQL, SHELL, HTML, etc.

Ditto for the shell conversion function.

I suppose you get the idea.

By the way, I do aim for performance that is acceptable in production
environments, because that is where security matters most.

Right now, the hit is in the 2% range. I hope this will be acceptable.

Wietse

Dan Scott

18 years ago

On 18/11/2007, Stefan Esser <stefan.esser@sektioneins.de> wrote:

> Good Morning,
>
> I just wanted to ask if there was ever a decision made that said tainted
> mode will go into PHP mainstream.
>
> Currently there are two implementations available:
>
> GRASP by Coresecurity
> * pro: byte level tainting which actually works
> * negativ: slow
>
> PHP Taint mode by Wietse Venema/IBM
> * pro: faster
> * negativ: broken design+insecure
>
> It is no secret that I don't like the idea of a taint mode in PHP
> because it cannot be made secure and fast at the same time.
> Coresecurity's GRASP is the best example for this it uses a secure
> design and is therefore slow. On the other hand it
> seems some people want the fast implementation of Wietse in the core
> which would be bad, because it is based on
> wrong assumptions and uses an insecure design that does only give a
> false sense of security.
>
> Examples for the wrong assumptions in PHP Taintmode:
> 1) _SERVER['PHP_SELF'] is not safe and allows XSS (and more) in many
> applications
> 2) Using mysql_real_escape_string() on user input does not make it safe
> for SQL. It only makes SQL strings safe.
> Example: "SELECT * FROM table WHERE id=".mysql_real_escape_string($id)
> is NOT secure but will result in no taint warning
> 3) Using htmlentities() on usr input does not make it safe for HTML
> output. It only makes it safe in some situations.
> Example:  echo '....<sometag  style="some-attribute:
> ',htmlentities($user_input),'">'. Will allow XSS through the style
> attribute without a taint warning
> Example2:  echo '....<img src="',htmlentities($user_input),'">'. Will
> allow XSS through javascript: URL (f.e. in Opera) without a taint warning

I believe the primary use case for taint mode would be to use it in
development: taint mode is a mode which can be turned on to give you
an idea of where your application may have exposed some
vulnerabilities; let you fix those identified vulnerabilities; then
turn off for production purposes. The speed of the implementation, if
this is indeed the intention for taint mode, would therefore be
irrelevant.

http://devzone.zend.com/node/view/id/1526#Heading3 suggests that we've
had this discussion before and almost came to agreement that taint
mode would be used as a development tool.

--
Dan Scott
Laurentian University

Stefan Esser

18 years ago

Hi Dan,

> I believe the primary use case for taint mode would be to use it in
> development: taint mode is a mode which can be turned on to give you
> an idea of where your application may have exposed some
> vulnerabilities; let you fix those identified vulnerabilities; then
> turn off for production purposes. The speed of the implementation, if
> this is indeed the intention for taint mode, would therefore be
> irrelevant.

The problem here is that both approaches fail to be completely secure
even when your test environment
has 100% code coverage. And I am speaking of real 100% ... Currently
there is no tool that can
ensure that. All PHP CC tools I know of so far will for example not
handle the ternary operator correctly.

The reason why both taint mode implementations fail are simple. Take the
following statement.

$sql['id'] = mysql_real_escape_string($_GET['id']);
$query = "SELECT * FROM table WHERE id=".$sql['id'];

Wietse's taint mode will consider this statement safe and never cry.
GRASP on the other hand will see that there is user supplied data in the
SQL query, but will ignore it
because it is a number. It will only react if $sql['id'] contains a
string. Atleast the very first version did
this.

This means currently both approaches would tell the developer that they
are safe, while they are in fact not.

Stefan Esser

Lukas Kahwe Smith

18 years ago

On 18.11.2007, at 22:40, Stefan Esser wrote:

> Hi Dan,
>> I believe the primary use case for taint mode would be to use it in
>> development: taint mode is a mode which can be turned on to give you
>> an idea of where your application may have exposed some
>> vulnerabilities; let you fix those identified vulnerabilities; then
>> turn off for production purposes. The speed of the implementation, if
>> this is indeed the intention for taint mode, would therefore be
>> irrelevant.
> The problem here is that both approaches fail to be completely secure
> even when your test environment
> has 100% code coverage. And I am speaking of real 100% ... Currently
> there is no tool that can
> ensure that. All PHP CC tools I know of so far will for example not
> handle the ternary operator correctly.

Stefan so what is your point then? Since neither can be 100% secure,
do not use any? Or just do not bundle either? There is nothing like
100% secure for anything that allows user access (and of course I am
not telling you any news with this).

I like the "its a development tool" kind of thinking that Dan brought
to the table. From what I understand the heavy duty approach could be
a very good tool to check for security risks and would just be one
tool in the shed along with suhoshin, xss scanner and not forget
common sense and security audits. Now if the two proposed solutions
are ready yet is another question (where I do trust your expertise -
and hopefully also of other security experts -  to give us a good
basis for judgement).

regards,
Lukas

David Zülke

18 years ago

Am 18.11.2007 um 22:53 schrieb Lukas Kahwe Smith:

> Stefan so what is your point then? Since neither can be 100% secure,
> do not use any? Or just do not bundle either?

Yes, that is exactly the way to go. To quote Yoda (and he would know):
"Do, or do not. There is no try.". Or, in contemporary words: do
things 100% properly, but if that is not possible, take a step back
and spare the world some half arsed attempt.


David

Lukas Kahwe Smith

18 years ago

On 19.11.2007, at 21:50, David Zülke wrote:

> Am 18.11.2007 um 22:53 schrieb Lukas Kahwe Smith:
>
>> Stefan so what is your point then? Since neither can be 100%
>> secure, do not use any? Or just do not bundle either?
>
> Yes, that is exactly the way to go. To quote Yoda (and he would
> know): "Do, or do not. There is no try.". Or, in contemporary
> words: do things 100% properly, but if that is not possible, take a
> step back and spare the world some half arsed attempt.

This makes no sense to me. There is nothing like 100% secure as long
as you dont pull the plug on the entire application. The only secure
application is one that hasnt been deployed anywhere. So the question
boils down to more "does this increase security sufficiently to make
the draw backs acceptable".

regards,
Lukas

David Zülke

18 years ago

>> Yes, that is exactly the way to go. To quote Yoda (and he would
>> know): "Do, or do not. There is no try.". Or, in contemporary
>> words: do things 100% properly, but if that is not possible, take a
>> step back and spare the world some half arsed attempt.
>
> This makes no sense to me. There is nothing like 100% secure as long
> as you dont pull the plug on the entire application. The only secure
> application is one that hasnt been deployed anywhere. So the
> question boils down to more "does this increase security
> sufficiently to make the draw backs acceptable".

And the answer is "no" ;) That's my point! Because one of the
drawbacks is that it won't cut down the number of dumb ignorants who
don't care about that stuff. Why would they, "teh PHP is making things
hax0r proof now" after all.


David

Stanislav Malyshev

18 years ago

> "Do, or do not. There is no try.". Or, in contemporary words: do things
> 100% properly, but if that is not possible, take a step back and spare
> the world some half arsed attempt.

It sounds nice, but from the practical point of view you can't make sure
code is 100% tested and 100% secure. There always will be combinations
of data, algorithm and state of the environment that you didn't think of
and didn't test for. By your logic, thus all security solutions and all
testing are useless. Obviously it is not so, and the reason for that is
that every tol that allows us to cover more security "territory" and
test for more problems is useful, even if it doesn't make your
application never fail.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

David Zülke

18 years ago

>> "Do, or do not. There is no try.". Or, in contemporary words: do
>> things 100% properly, but if that is not possible, take a step back
>> and spare the world some half arsed attempt.
>
> It sounds nice, but from the practical point of view you can't make
> sure code is 100% tested and 100% secure. There always will be
> combinations of data, algorithm and state of the environment that
> you didn't think of and didn't test for. By your logic, thus all
> security solutions and all testing are useless. Obviously it is not
> so, and the reason for that is that every tol that allows us to
> cover more security "territory" and test for more problems is
> useful, even if it doesn't make your application never fail.

I didn't mean that any kind of testing is useless :)

The thing is, however, that a taint mode feature could not possibly
cover all potential security issues, and would therefor give those
users that do not have the slightest clue about security anyway a
false feeling of safety. We've had that before with magic quotes and
the like and it didn't work. Just look at the discussions here. If my
neighbor's squirrel farts in the wrong direction, and I ate cornflakes
less than an hour ago, there's a 23 percent chance that the untainting
done by htmlentities() won't be enough. That is just not going to cut
it.

An untaint() approach - all for it (yes, the noobs that don't give a
damn are going to use it because "it just works", but no, that
shouldn't bother us, at least they have been warned). But some
implicit guessing magic that, once again, means people are gonna
switch their brains off - please not.

- David

Stefan Priebsch

18 years ago

Hey David,

David Zülke schrieb:

> bother us, at least they have been warned). But some implicit guessing
> magic that, once again, means people are gonna switch their brains off -
> please not.

Frankly, I don't care about people that switch their brains off. If one
doesn't care about security, or doesn't understand the related problems,
they'll always be able to write crappy code, no matter what.

I'd love to see a taint mode in PHP because it would help me make stuff
I use and work on (at least) a little more secure - without a lot of effort.

Regards,

Stefan

--
>e-novative> - We make IT work for you.

e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch

http://www.e-novative.de - GnuPG Key: 0x7DB67F7F

Christian Schneider

18 years ago

David Zülke wrote:

> An untaint() approach - all for it (yes, the noobs that don't give a
> damn are going to use it because "it just works", but no, that shouldn't

Most people here seem to agree that it would be valuable tool for
themselves to be able to taint/untaint data. Wietse's approach is very
programmer friendly (few false positives, little impact on code
performace which is handy even on development systems) and the only
major drawback seems to be the perception it could create: "No warnings
means you're safe".

I see it as an additional tool and could live with a very basic
interface (two or three taint bits I can set, clear and check) but have
to admit that Wietse's approach and enhancened comfort fits very well in
our world.

The filter mechanism sits at the wrong end of the chain for us: We want
to keep data in its original state as long as possible and sanitize it
once it is used.

Not having a tool for this at all seems like a big loss to me so I hope
we can agree on something (even if it is a minimalistic Zend extension
to allow a PECL module for taint).

- Chris

Stanislav Malyshev

18 years ago

> The problem here is that both approaches fail to be completely secure
> even when your test environment

I don't think taint mode can be truly considered as security feature.
It's rather a feature that would remind the developer he needs to think
about security. Just as an alarm clock can wake you up, but can't ensure
you actually will go to work and do something productive there, tainting
can tell you that you need to take care of the variable, but can't
ensure the care was right. While I agree with you on the analysis of the
escaping security, I do not think that this necessarily makes the whole
idea of tainting worthless.

> has 100% code coverage. And I am speaking of real 100% ... Currently
> there is no tool that can
> ensure that. All PHP CC tools I know of so far will for example not
> handle the ternary operator correctly.

Most CC tools I know work on line-level, which makes quite hard for them
to report on same-line branches, such as ternary operator. Of course
they could report on opcode-level, but that'd be hard to read for the
user :) So I believe most tools actually know about ternary operators,
but can't report about them.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

Ezequiel Gutesman

18 years ago

Stefan Esser wrote:

> Hi Dan,
>> I believe the primary use case for taint mode would be to use it in
>> development: taint mode is a mode which can be turned on to give you
>> an idea of where your application may have exposed some
>> vulnerabilities; let you fix those identified vulnerabilities; then
>> turn off for production purposes. The speed of the implementation, if
>> this is indeed the intention for taint mode, would therefore be
>> irrelevant.
> The problem here is that both approaches fail to be completely secure
> even when your test environment
> has 100% code coverage. And I am speaking of real 100% ... Currently
> there is no tool that can
> ensure that. All PHP CC tools I know of so far will for example not
> handle the ternary operator correctly.
>
> The reason why both taint mode implementations fail are simple. Take the
> following statement.
>
> $sql['id'] = mysql_real_escape_string($_GET['id']);
> $query = "SELECT * FROM table WHERE id=".$sql['id'];
>
> Wietse's taint mode will consider this statement safe and never cry.
> GRASP on the other hand will see that there is user supplied data in the
> SQL query, but will ignore it
> because it is a number. It will only react if $sql['id'] contains a
> string. Atleast the very first version did
> this.
>
> This means currently both approaches would tell the developer that they
> are safe, while they are in fact not.
>
> Stefan Esser
>

Hi all, I'm one of CORE GRASP's developers. GRASP was designed to be
used in production stage and hence it is unacceptable to have false
positive and false negative alarms.

As GRASP's objective is to enhance protection in run-time it was only
designed to block on-going attacks and not to warn the developer about
insecure coding habits. We think that Venema's Taint mode is a lot more
helpful in this task.

Going back to Stefan's example:

> $sql['id'] = mysql_real_escape_string($_GET['id']);
> $query = "SELECT * FROM table WHERE id=".$sql['id']

It is true that GRASP won't raise an alarm unless $sql['id'] has
non-numeric characters. This was a design decision since our description
of an attack does not include this example. After analyzing this
example, we cannot see how an attacker could perform a SQL-Injection
attack only with numeric characters; that's why GRASP will not detect
this as an attack.

Ezequiel Gutesman

Markus Fischer

18 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Ezequiel Gutesman wrote:

> Going back to Stefan's example:
>
>> $sql['id'] = mysql_real_escape_string($_GET['id']);
>> $query = "SELECT * FROM table WHERE id=".$sql['id']
>
> It is true that GRASP won't raise an alarm unless $sql['id'] has
> non-numeric characters. This was a design decision since our description
> of an attack does not include this example. After analyzing this
> example, we cannot see how an attacker could perform a SQL-Injection
> attack only with numeric characters; that's why GRASP will not detect
> this as an attack.

Unless I'm missing something, in this example I don't see anything
forcing 'id' to be actually numerical. Unless forced to be numerical,
see http://webappsec.org/projects/articles/091007.shtml#p4 for an
example how to exploit it; even with mysql_real_escape_string().

- - Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHQg8s1nS0RcInK9ARAhPRAJ9qtqG1bMMCoVfTM3A3j2pidt1KVgCeI2Lv
pYcNBRegKEvqjArXkWJmtco=
=vQdC
-----END PGP SIGNATURE-----

(Wietse Venema)

18 years ago

Stefan Esser:

> 2) Using mysql_real_escape_string() on user input does not make it safe
> for SQL. It only makes SQL strings safe.
> Example: "SELECT * FROM table WHERE id=".mysql_real_escape_string($id)
> is NOT secure but will result in no taint warning

Can you give a specific example? I'd like to know how likely such
things would be in real code.

> 3) Using htmlentities() on usr input does not make it safe for HTML
> output. It only makes it safe in some situations.
> Example:  echo '....<sometag  style="some-attribute:
> ',htmlentities($user_input),'">'. Will allow XSS through the style
> attribute without a taint warning
> Example2:  echo '....<img src="',htmlentities($user_input),'">'. Will
> allow XSS through javascript: URL (f.e. in Opera) without a taint warning

Or they could encrypt the entire URL and include a decryptor
(javascript or some other language) in the HTML text. Detecting
threats that involve script/applet/etc execution requires the
ability to realistically simulate every browser. I haven't
solved that one yet.

That doesn't mean that I should give up trying to warn people about
known-to-be-bad coding practices. I just can't warn them about all
possible ways to screw up.

Wietse

Stefan Esser

18 years ago

Wietse Venema schrieb:

> Stefan Esser:
>
>> 2) Using mysql_real_escape_string() on user input does not make it safe
>> for SQL. It only makes SQL strings safe.
>> Example: "SELECT * FROM table WHERE id=".mysql_real_escape_string($id)
>> is NOT secure but will result in no taint warning
>>
>
> Can you give a specific example? I'd like to know how likely such
> things would be in real code.
>

I have to search for an example where mysql_real_escape_string is used
wrongly like this....

However the "bigger" problem is that if the statement is like

"SELECT * FROM table WHERE id=$id"

which *IS* quite common in insecure code your patch will give the
following warning: "contains data that is not converted with
mysql_real_escape_string()"

This gives the message to the uneducated user (and that is the one you
want to protect) to write something like this in his code.

"SELECT * FROM table WHERE id=".mysql_real_escape_string($id)

The PHP taint mode will stop crying and that teaches the developer the
WRONG message.

And just look into blogs... People even add user input into SQL comments
and wrongly use mysql_real_escape_string() there, which is completely
nonsense.


Stefan Esser

Lukas Kahwe Smith

18 years ago

On 19.11.2007, at 09:00, Stefan Esser wrote:

> Wietse Venema schrieb:
>> Stefan Esser:
>>
>>> 2) Using mysql_real_escape_string() on user input does not make
>>> it safe
>>> for SQL. It only makes SQL strings safe.
>>> Example: "SELECT * FROM table WHERE id=".mysql_real_escape_string
>>> ($id)
>>> is NOT secure but will result in no taint warning
>>>
>>
>> Can you give a specific example? I'd like to know how likely such
>> things would be in real code.
>>
> I have to search for an example where mysql_real_escape_string is used
> wrongly like this....
>
> However the "bigger" problem is that if the statement is like
>
> "SELECT * FROM table WHERE id=$id"
>
> which *IS* quite common in insecure code your patch will give the
> following warning: "contains data that is not converted with
> mysql_real_escape_string()"
>
> This gives the message to the uneducated user (and that is the one you
> want to protect) to write something like this in his code.
>
> "SELECT * FROM table WHERE id=".mysql_real_escape_string($id)
>
> The PHP taint mode will stop crying and that teaches the developer the
> WRONG message.
>
> And just look into blogs... People even add user input into SQL
> comments
> and wrongly use mysql_real_escape_string() there, which is completely
> nonsense.

Actually you are missing the connection object in that
mysql_real_escape_string() call to make sure that the connection
encoding is taken into account. I think its very important that we
make sure people do not forget this one as its a new addition. So the
more examples we have showing with the connection object as the 2nd
parameter the better.

regards,
Lukas

(Wietse Venema)

18 years ago

Stefan Esser:
[ Charset ISO-8859-1 unsupported, converting... ]

> Wietse Venema schrieb:
> > Stefan Esser:
> >
> >> 2) Using mysql_real_escape_string() on user input does not make it safe
> >> for SQL. It only makes SQL strings safe.
> >> Example: "SELECT * FROM table WHERE id=".mysql_real_escape_string($id)
> >> is NOT secure but will result in no taint warning
> >>
> >
> > Can you give a specific example? I'd like to know how likely such
> > things would be in real code.
> >
> I have to search for an example where mysql_real_escape_string is used
> wrongly like this....
>
> However the "bigger" problem is that if the statement is like
>
> "SELECT * FROM table WHERE id=$id"
>
> which *IS* quite common in insecure code your patch will give the
> following warning: "contains data that is not converted with
> mysql_real_escape_string()"
>
> This gives the message to the uneducated user (and that is the one you
> want to protect) to write something like this in his code.
>
> "SELECT * FROM table WHERE id=".mysql_real_escape_string($id)
>
> The PHP taint mode will stop crying and that teaches the developer the
> WRONG message.

I can certainly update the warning message, with a reminder to put
query arguments inside quotes. The idea is to help the programmer
to the right thing. It is currently not possible for a programming
language implementation to guarantee that the programmer won't make
mistakes.

Some mistakes (like the one that requires exection in the browser)
can be found by emulating the browser, and some mistakes can be
found by emulating the user. I'll try to report the mistakes today
that I can report today.

Wietse

troels knak-nielsen

18 years ago

If taint-mode is intended for testing only, it would never be
something, which was turned on per default. Then maybe a tool such as
php-sat ( http://www.program-transformation.org/PHP/PhpSat ) is a
better solution? It seems to me like there is a rather big overlap
between the projects.

--
troels

(Wietse Venema)

18 years ago

troels knak-nielsen:

> If taint-mode is intended for testing only, it would never be
> something, which was turned on per default. Then maybe a tool such as
> php-sat ( http://www.program-transformation.org/PHP/PhpSat ) is a
> better solution? It seems to me like there is a rather big overlap
> between the projects.

php-sat does static analysis. With static analysis one looks at
source code without executing it. This is a fundamentally different
approach than run-time taint analysis (which executes PHP code).

Each approach has its strong and weak points.

Static analysis can examine code paths that rarely execute, but
its understanding of those code paths is necessarily limited.

Run-time analysis is limited to code paths that actually execute.
It proves more of its value when it can be left turned on, and this
is why I am paying attention to performance.

Wietse

Sebastian Nohn

18 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Stefan,

Stefan Esser wrote:

> GRASP by Coresecurity
> * pro: byte level tainting which actually works
> * negativ: slow
>
> PHP Taint mode by Wietse Venema/IBM
> * pro: faster
> * negativ: broken design+insecure

I don't see a big problem with having a slow but working taint mode in
development environments while not having a taint mode in production
environments. The question - as always - is, how big the performance
impact really is.

- - Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)

iD8DBQFHQTsxsvwfldR9VeARAj0dAJ9KGDy0g92AK0sB+kpWxGn3k52NjACgnbt8
3J6K0b7bOuIXWrH3F5ylnHs=
=kb6h
-----END PGP SIGNATURE-----