On 07.05.2021 22:39, Ram Rachum wrote: > Hi Marc. > > On Fri, May 7, 2021 at 11:32 PM M.-A. Lemburg <[email protected] > <mailto:[email protected]>> 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/ _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/YAGN7N45TCTLFNQNGC2RKVLHIHMBTQ76/ Code of Conduct: http://python.org/psf/codeofconduct/
