Marc,

You might have misunderstood me. I am not recommending sending the database raw strings without parameters, but rather that i-strings turn things into parameters and its impossible to mess up. Let me explain a little. 

In sqlalchemy, you can use a format such as "update items set a=:value where id=:item_id" then you tell it the value of the parameters. SQLAlchemy then takes the :something part of the string and turns it into a parameter ($1, $2, etc). The problem being however, there is nothing stopping me from doing an f string on accident: f"update items set a={something} where id=:value". Because f-strings are eager, sqlalchemy cant protect you, you are now vulnerable to injection. 
But with i-strings, because they are not eager, it would actually know that you passed in the value as a variable, and turn it into a parameter. It knows the difference between the static part of the query and the dynamic part of the query, so it can actually protect you from yourself, or protect early engineers who don't even know what injection is. 

Nick


On Fri, May 7, 2021, 2:48 PM M.-A. Lemburg <mal@egenix.com> wrote:
On 07.05.2021 22:39, Ram Rachum wrote:
> Hi Marc.
>
> On Fri, May 7, 2021 at 11:32 PM M.-A. Lemburg <mal@egenix.com
> <mailto:mal@egenix.com>> wrote:
>
>     On 07.05.2021 21:40, Nick Humrich wrote:
>     > PEP 501 was deferred because more learning and time was wanted after
>     introducing
>     > f-strings. Now that it has been 5 years, I wonder what the possibilities of
>     > revisiting PEP 501 are. 
>     >
>     > I recently had the experience of using javascript "tagged template
>     literals" and
>     > was able to build a SQL string parser that is impossible to have SQL injection
>     > with. This is done by having the database connection object only accept a
>     > certain type of object, and all sql tagged template literals become that
>     object.
>     > Because variables are lazy evaluated, the template function can turn all
>     dynamic
>     > inputs into parameters in a SQL query. It is impossible for a dev to
>     > accidentally add a user imputed string as a literal.
>     > PEP 501 already mentions how templates (i-strings?) can solve injection.
>     This is
>     > a very incredible goal. Injection has been the #1 vulnerability on OWASP for
>     > over 10 years, and has been in the top 5 the entire time OWASP has existed
>     > (almost 20 years now).
>     > We have an opportunity to completely remove injection attacks.
>
>     I think you ought to not use SQL injection as the primary argument
>     for i-strings.
>
>     The DB API highly recommends passing any arguments
>     to a SQL to the database via binding parameters and let the database
>     do the binding of the SQL template on the server side.
>
>     Sending those SQL templates and the parameters separately to the
>     database is not only safer, but also a lot more efficient and allows
>     for the database to much better manage query plan caching and reuse.
>
>
> Interesting. When you do that in Python, does that mean something like %s in the
> SQL query, and then after the query a list of arguments in the same order as the
> %s tokens? Because if that's the case, maybe it'll be better to use an i-string
> there, and NOT have the Python layer format the string, but use that i-string to
> send the parameters separately to the database. It might be easier to read that way.
  
The %s tokens in %-formatted SQL strings for e.g. PostgreSQL
are sent to the database as-is. The binding of the parameters,
which are passed separately as a tuple, is done by the database
and not in Python, even though the format looks a lot like the
%-formatting used in Python.

There are other formats as well, e.g. the ? token format
used in ODBC or the :1 tokens used for e.g. Oracle.

See https://www.python.org/dev/peps/pep-0249/#paramstyle for
details.

>     Even with i-strings we should *not* recommend doing the binding
>     of SQL strings in the Python application.
>
>     There are other use cases where lazy binding can be useful, though,
>     e.g. when you don't know whether the interpolation will actually
>     get used (logging) or where you may want to render the template
>     in a different or extended namespace.
--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, May 07 2021)
>>> Python Projects, Coaching and Support ...    https://www.egenix.com/
>>> Python Product Development ...        https://consulting.egenix.com/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               https://www.egenix.com/company/contact/
                     https://www.malemburg.com/