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