Hacker News new | ask | show | jobs
by wruza 3209 days ago
I checked it for PostgreSQL right now, and it seems that libpq can send them OOB via PQexecParams() and networked integer buffers. But that's not the case with OpenResty's pgmoon driver, which doesn't have such an interface. E.g. Lapis framework built on top of that simply escape_literal()-izes all arguments and interpolates right into query text. So, YMMW with specific (or generic) drivers.

Placeholders are there for those who tries to concatenate queries by hand; having them properly escaped in protocol should not defeat client-side security purpose.
1 comments
anton_gogolev 3208 days ago
You can never properly escape user input, so this escape_literal() is a ticking timebomb.
link
icebraining 3208 days ago
How come it's impossible to properly escape user input? I get that it's hard if the format is complex, but I don't see what makes it categorically impossible, especially for a simple format like an SQL string. You just double every single quote and then surround the whole thing with single quotes.
link
anton_gogolev 3208 days ago
> ...every single quote...

And then you come across \u0027 and you're screwed.

link
wruza 3207 days ago
Do you know any decent server that interprets 6-char \uxxxx sequences as part of its top-level query syntax? I mean, how do you safely pass '\u0027' literal to it anyway? If you can't, then its literals and escaping are broken by design, so it is good to know from the start of using it.

Edit: removed double backslash from literal to not confuse it with host language's escaping.

link
icebraining 3208 days ago
If you use a broken RDBMS, maybe. The standard is quite clear, and that certainly doesn't work in PortgreSQL.
link