On Tue, May 9, 2017 at 9:43 PM, Chapman Flack <c...@anastigmatix.net> wrote: > That's where the appident.cookie() function comes in. You just > query it once at session establishment and remember the cookie. > That allows your code to say: > > SET SESSION ON BEHALF OF 'joe user' BECAUSE I HAVE :cookie AND I SAY SO; > > and Mallory can't inject that because he doesn't have :cookie and the > appident.cookie() function only succeeds the first time.
I have for a long time been interested in having a protocol-level method for setting the session identity. That is, instead of sending "SET SESSION AUTHORIZATION 'rhaas'" wrapped in a Query message, you'd send some new protocol message that we invent that nails down the session authorization and doesn't allow it to be changed except by another protocol message. I feel like the usefulness of this for connection pooling software is pretty obvious: it's a lot easier for the pooler to disallow a certain protocol message than a certain SQL command. But maybe we could generalize it a bit, so that it can work for any GUC. For example, let the client send some new SetVariableViaProtocol message with two arguments, a GUC name and a value. The server treats this just like a SET command, except that once you've done this, the variable can't later be changed from SQL. So now you don't even need the cookie, and the client can't try to guess the cookie. You just tell the server - via this protocol message - to nail down session_authorization or application_name or appuser.thunk to some value of your choice, and it's invulnerable to SQL injection thereafter. Whaddaya think? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers