On Tue, May 9, 2017 at 9:43 PM, Chapman Flack <chap@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