4 ms·
Unfortunately when defaults are inherently insecure, they lead to people building insecure systems. If every single parameterized SQL command needs to include (
by sehrope 13y ago
Unfortunately when defaults are inherently insecure, they lead to people building insecure systems. If every single parameterized SQL command needs to include (possibly multiple) escapes then it'll be missed in some places.
It's unnecessary anyway. It would be way better would be if the parameters were bound as named parameters. Ex:
location ~ /articles/(?<id>\d+) {
postgres_pass database;
rds_json on;
postgres_query HEAD GET "SELECT * FROM articles WHERE id = $id";
postgres_rewrite HEAD GET no_rows 410;
}
See how $id has no quotes around it? The DB driver should parse the parameter and bind it as a string in that position. If you need to use it as a different data type (ex: integer) then you can do an explicit type conversion. That's how you prevent SQL injection.
- jeffdavis 13y ago"The DB driver should parse the parameter and bind it as a string in that position. If you need to use it as a different data type (ex: integer) then you can do an explicit type conversion." Not sure exactly what you mean here. The protocol and libpq support sending literal values entirely outside of the query itself. There is no reason for the DB driver to do any parsing.
- sehrope 13y agoMiscom on my part. By driver I meant the nginx module that's calling out to libpq (which would more accurately be referred to as the DB driver). I meant that libpq supports bind variables and the nginx module should be using them rather than performing a string substitution.