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/