David Fetter <da...@fetter.org> writes:
> On Fri, May 05, 2017 at 02:20:26PM -0400, Robert Haas wrote:
>> On Thu, May 4, 2017 at 10:59 AM, Chapman Flack <c...@anastigmatix.net> wrote:
>>> invalid input syntax for integer: "21' && 1=2)) Uni/**/ON
>>> SEl/**/eCT 0x646665743166657274,0x646665743266657274,
>>> 0x646665743366657274 -- "
>> Now that is choice. I wonder what specific database system that's
>> targeting...
> It could well be targeting some class of pipeline to the database,
> too, for example one that removes comments and/or un-escapes.
Yeah. It's a bit hard to see a database's parser treating "Uni/**/ON"
as UNION, but if some stack someplace had a keyword check ahead of
a comment-stripping step, maybe that could do something useful.
> It occurs to me that psql's habit of stripping out everything on a
> line that follows a double dash might be vulnerable in this way, but
> I wouldn't see such vulnerabilities as super easy to exploit, as psql
> isn't usually exposed directly to input from the internet.
I don't think that's a problem: while psql will remove "--" and everything
following it until newline, it won't remove the newline. So there's still
a token boundary there. If we tried to strip /*...*/ comments we'd have
to be more careful.
As far as the actual thread topic goes, I tend to agree with Robert's
doubt that there's enough utility or consensus for this.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
