On Wed, Jun 23, 2021 at 8:09 PM Bruce Weirdan <weir...@gmail.com> wrote:
>
> > - String + int concatenation isn't an injection risk.
>
> I think this demonstrates it very well could be:
> https://externals.io/message/114988#115038
>
> --
> Best regards,
> Bruce Weirdan
> mailto:weir...@gmail.com
Respectfully, the example you linked is **not** an example of an
Injection vulnerability. The failure condition of this query is
"return all rows from the table already being queried", not "return
arbitrary data the attacker selects from any table that the
application can read".
Being able to arbitrarily select a column is a bad design (and you
should feel bad, as per the meme, if you let this happen in
production), but it differs from Injection vulnerabilities in one
fundamental way: The attacker cannot change the structure of the SQL
query being executed.
Here's an example of an injection vulnerability:
`$pdo->prepare("SELECT b, c, d, e FROM table WHERE a = '$foo'");`
If you set $foo to `' UNION SELECT NULL, NULL, NULL, pwhash FROM
accounts WHERE username = 'Admin`, you'll leak contents from *another
table* in the SQL result. This is the danger posted by
string-to-string concatenation, and what we mean by SQL Injection.
This doesn't have to stop all dumb things that PHP developers can do.
It's enough to only stop the catastrophically dumb things (especially
if we don't call the function `is_trusted()`).
You can still invent scenarios where int-to-string concatenation
results in buggy behavior, but it isn't the game-over security
vulnerability that string-to-string concatenation is. And that's the
entire point.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
