On Sat, 26 Jun 2021 at 13:47, Rowan Tommins <rowan.coll...@gmail.com> wrote:
> the actual bug will almost certainly have happened somewhere else in the
> program, and you'll need to trace the data flow of $foo and $bar to find out
> where.
>
That depends on what you mean by bug. In particular I don't agree that
"The actual root cause is in getColor(),". Whether user-controlled
data is dangerous or not depends on where it's used, not where it's
coming from.
For me, the bug when $up->getColor() changes from returning a literal
string to a user supplied value is in this line of code:
"<div style='color: " . $up->getColor() . "'>";
Where a programmer has assumed that the value returned by
$up->getColor() is a literal string. It's not a bug for that function
to return a user controlled value.
> so tracking the root cause could be just as difficult.
Not as difficult. It would give the exact line of code where the bad
assumption was made.
literal_concat("<div style='color: ", $up->getColor(), "'>");
When $up->getColor() is changed from returning a literal string to a
user controlled one, it would throw an exception. You could look at
the exception, see that the 2nd parameter isn't literal and is coming
from the getColor method, and know this code isn't safe and needs to
be changed to something that can do the appropriate escaping.
Even if the origin of the value was more obscure as you suggest, so
maybe something like:
function getDiv($color) {
$div = literal_concat("<div style='color: ", $color, "'>");
// ...
return $div;
}
$color = $up->getColor();
$html .= getDiv($color);
Although the origin of where the variable comes from wouldn't be in
the stacktrace, the error still would be.
There is a line of code that has a bad assumption of whether $color is
a literal string or not, and it's that line of code that needs to be
changed, to use something that understands HTML escaping, in
particular how to escape user input for html attribute context.
So even when the origin of a value might be hard to understand, the
precise line of code that has the bad assumption would be part of the
stacktrace, which makes figuring out the problem be a lot easier.
That's why it worked for Google. By not having to understand where
variables come from, but only having the error be where there are used
inappropriately, you completely get rid of the "having to understand a
large chunk of code" problem, and instead only have to consider where
the variables are being used, and in what context they are being used.
cheers
Dan
Ack
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
