Re: backslash-dot quoting in COPY CSV

On Fri, Jan 25, 2019 at 01:01:22PM +0100, Daniel Verite wrote:
> Bruce Momjian wrote:
>
> > but I am able to see the failure using STDIN:
> >
> > COPY test FROM STDIN CSV;
> > Enter data to be copied followed by a newline.
> > End with a backslash and a period on a line by itself, or an EOF
> > signal.
> > "foo
> > \.
> > ERROR: unterminated CSV quoted field
> > CONTEXT: COPY test, line 1: ""foo
> >
> > This seems like a bug to me. Looking at the code, psql issues the
> > prompts for STDIN, but when it sees \. alone on a line, it has no idea
> > you are in a quoted CSV string, so it thinks the copy is done and sends
> > the result to the server. I can't see an easy way to fix this. I guess
> > we could document it.
>
> Thanks for looking into this.
>
> \copy from file with csv is also affected since it uses COPY FROM
> STDIN behind the scene. The case of embedded data looks more worrying
> because psql will execute the data following \. as if they were
> SQL statements.
>
> ISTM that only ON_ERROR_STOP=on prevents the risk of SQL injection
> in that scenario, but it's off by default.

You are correct that someone having data that is SQL commands would be
able to perhaps execute those commands on restore. pg_dump doesn't use
CSV, and this only affects STDIN, not files or PROGRAM input. I think
the question is how many people are using CSV/STDIN for insecure data
loads?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +