Re: Best way to deal with quote_literal issue? - Mailing list pgsql-general

From Florian G. Pflug
Subject Re: Best way to deal with quote_literal issue?
Date
Msg-id 44AD9A3E.4070406@phlo.org
Whole thread Raw
In response to Best way to deal with quote_literal issue?  ("Karen Hill" <karen_hill22@yahoo.com>)
List pgsql-general
Karen Hill wrote:
> Hello.
>
> I have client software that I wrote which uses parameters in  function
> calls to postgresql.  I use quote_literal in postgresql functions.
> That means  I get data that is quoted when it finally ends up in the
> tables which I don't want.
>
> I know that you shouldn't trust data sent from the client, which is why
> I use quote_literal on the server side, and I also know using
> parameters is the best way to write client software which access an
> RDBMS.
>
> I don't want to remove the quote_literal just in case someone writes a
> new client and forgets to use parameters thereby exposing an SQL
> injection risk.  Nor do I want to just keep quote_literal and dump
> using parameters.
>
> What is the best and most theoretically sound way to deal with this?
If you don't use "execute" in your function, you don't need to worry
about sql injection. Postgres handles that for you

If you use execute, then you need to use quote_literal, but that shouldn't
result in storing a quoted value then, because the parser strips the quotes
again.

If you want to protect the sql-statement that _calls_ the function, then
quote_literal won't help anyway - you'll need to use whatever quoting functions
your client library includes (PQescape in the C client, I believe). Doing that
protection in the function itself is impossible, because when your function is
called, it's already too late.

greetings, Florian Pflug

pgsql-general by date:

Previous
From: "Florian G. Pflug"
Date:
Subject: Re: Long term database archival
Next
From: Ryan Gran
Date:
Subject: PANIC: XX000: right sibling is not next child in "pg_depend_reference_index"