On Thu, Jun 24, 2021 at 5:22 AM Stephen Reay <php-li...@koalephant.com> wrote:
> > If you **inject a `1=1` clause where one didn't exist before**, that's
> > injection. Notice the introduction of an OR operator in the examples
> > you cited.
>
> Please, explain to us all, how `where foo=‘bar’ OR 1=1` is functionally
> different than `where 123=123` because the developer screwed the pooch in
> some specific condition and passed the ID twice, rather than the column name
> and the id, respectively.
SQL injection occurs when you send specially crafted user input and it
injects SQL code.
**If you aren't injecting SQL, it's not SQL injection.** I don't
understand why this isn't clicking for you.
The scenario you've concocted is a Confused Deputy. Logic bugs can be
severe. Logic bugs can be sev:crit security issues! But if you aren't
injecting SQL, calling it SQL Injection is wrong.
Arguing from consequences ("SQL Injection can drop a table! This logic
bug can drop a table! Therefore they're the same thing") rather than
the specific properties of the system design failure in question ("one
injects code, the other doesn't") isn't a useful way to classify
vulnerabilities.
To reiterate:
1. I never claimed that it wasn't a bug.
2. I never claimed it wasn't impactful.
3. I never claimed it wasn't security-affecting.
I've simply said that this isn't an example of SQL Injection, because
nothing is being *injected*.
> >
> > My classification of the original example as "Not Injection" has
> > nothing to do with the fact that numbers are being compared with
> > numbers. Rather, there was no code injection.
> >
> >> Also, while researching the specifics of what is considered an “SQL
> >> Injection” I came across an article, that talks specifically about the
> >> dangers of allowing user input (i.e. the thing `is_trusted` is meant to
> >> prevent) as a column or table identifier. It’s from this little
> >> organisation, you may have heard of them: “Paragon Initiative”
> >> (https://paragonie.com/blog/2015/05/preventing-sql-injection-in-php-applications-easy-and-definitive-guide).
> > Snark is unnecessary.
>
> You call it snark, I call it ironic hypocrisy.
In my original email, I said. "Outside the chr()/pack()/sprintf()/etc.
technique demonstrated above, there's no risk of injection inherent to
concatenating a trusted string with an untrusted integer." You brought
up a high-severity logic bug that could happen if someone concatenates
variables with wild abandon, but it's still not an example of
**injection**.
If you're going to call someone a hypocrite (which is a needless
personal attack), take care that you're actually correct when you do
so.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
