Hacker News new | ask | show | jobs
by nezirus 1204 days ago
That database stuff looks horrible. Why do they feel the need to introduce DB query templating into string templates? No matter what you do on the client side, the database engine itself should escape/validate the data. Didn't we learn that lesson with PHP?

In addition to that, not every database needs prepared statements for safe queries e.g. "Parametrized queries" in PostgreSQL (available in libpq as PQExecParams and exposed in many other higher level languages)

3 comments

The database stuff looks like an example, and shows how you could extend the template system in a way that doesn't introduce security problems.
That is exactly the point, you should not use general string templating system for SQL queries, together with "roll your own" escape and validation mechanisms. I really don't see why they included that part, if not to show how to shoot yourself in the foot.
I am very confused by your comments. PHP developers thought "sanitizing" strings aka escaping and validating strings is enough to get rid of SQL injections and that is how they ended up with multiple iterations of escaping functions. The problem, which is the separation of code from data, has not been solved and that is why it is a bad idea. The SQL example template in the article uses positional parameters via JDBC and is therefore completely safe to use. It is impossible to get it wrong except by using STR which is obviously the wrong template processor.
There is no roll your own escape mechanics. The example uses prepared statements.
>No matter what you do on the client side, the database engine itself should escape/validate the data. Didn't we learn that lesson with PHP?

You apparently didn't learn any lesson from PHP. The impossibility of the database engine to distinguish a code from a data character is what lead to SQL injections in the first place.

It doesn't matter whether you replace the template expression with a ? or with $1. The database receives the parameters outside the SQL query and treats them as user input either way.

You have to escape the things before they reach the database engine. Prepared statements do this via ? Placeholders but they are hard to read. With this you get named placeholders, much nicer to read.