Fabien COELHO wrote: > I'm not fully convinced by this feature: using multiple queries is a > useful trick to reduce network-related latency by combining several > queries in one packet. Devs and even ORMs could use this trick.
It's proposed as an option. For apps that intentionally put multiple commands in single PQexec calls, or for apps for which the deployer doesn't know or care whether they do that, the setting should be kept to its default value that let such calls pass, as they pass today. In my understanding of the proposal, there is no implication that intentionally using such multiple commands is bad, or that it should be obsoleted in the future. It's only bad in the specific case when this possibility is not used normally by the app, but it's available to an attacker to make an attack both easier to mount and more potent than a single-query injection. This reasoning is also based on the assumption that the app has bugs concerning quoting of parameters, but it's a longstanding class of bugs that plague tons of low-quality code in production, and it shows no sign of going away. > Many SQL injection attacks focus on retrieving sensitive data, > in which case "' UNION SELECT ... --" would still work nicely. Should we > allow to forbid UNION? And/or disallow comments as well, which are > unlikely to be used from app code, and would make this harder? If pg is to > provide SQL injection guards by removing some features on some > connections, maybe it could be more complete about it. It looks more like the "training wheel" patch that was discussed in https://commitfest.postgresql.org/13/948/ rather than something that should be in this patch. This is a different direction because allowing or disallowing compound statements is a clear-cut thing, whereas making a list of SQL constructs to cripple to mitigate bugs is more like opening a Pandora box. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers