monacoremo / postgrest-sessions-example Goto Github PK

Just revisiting your project and noticed the tests.py.

Would you be open to a PR for changing them to use https://github.com/robwhitby/shakedown?

I want to give it a try and see if gets the tests shorter and maybe more readable.

Just a reminder that it would be great to have this on the postgrest docs!

I think you could add this as a how-to(like in http://postgrest.org/en/v7.0.0/how-tos/providing-images-for-img.html) since it's hard to follow the sequence of the current tutorials on the docs.

Ideally I would also cleanup http://postgrest.org/en/v7.0.0/auth.html and make it only about roles and then have JWT and Sessions be two different topics. But you might refer to authentication sequence to keep the content shorter.

Would that make this example too complex? TBD

The ideas you use on deploy-local.sh are really great. Isolating the db cluster by using a unix socket and being locale-agnostic.

I was wondering if you looked at pg_tmp(included in nixpkgs). I was thinking that perhaps it could simplify the setup.

Any postgrest application relying on pre-request for authentication is trivial to ddos and there is no way to block it.
PostgREST still has PostgREST/postgrest#1094 but at least that can be mitigated at the proxy level easily.
You've fixed a small problem (can't invalidate a JWT which can be easily worked around and that only affects 1 account) and created a big one, anyone without a valid session can mount a ddos attack (your service is trivially ddos-able, because "db-connection slots" are very limited and absolutely every request needs to execute this function, even the bad ones)

secondary point, i know pgcrypt docs say gen_random_bytes is cryptographically strong but i think the way you are using it is not.

from https://github.com/postgres/postgres/blob/7559d8ebfa11d98728e816f6b655582ce41150f3/src/port/pg_strong_random.c

Our definition of "strong" is that it's suitable for generating random
salts and query cancellation keys, during authentication.

That function (and the underlying libs it relies on) does not have enough entropy to be secure. (i am not crypto expert or even have exp. in the field but) If it were this trivial to generate random session ids, PHP would just use urandom output as session ids (as it's done here at the core) and not use things like user ip,time,... as entropy when generating the session id (and even then there were enough vulnerabilities in this area in the past).

as a conclusion: This is a good/interesting "exercise" but it's way less "secure" as implemented here then just plain JWT's (and certainly not as a "recommended" way to implement sessions).
If you are really worried about "revocation problems" of jwt (which imo are way overblown* in practice) you can trivially use something like https://github.com/bungle/lua-resty-session and replace on the fly JWTs with plain cookies at the proxy level.

* assuming jwt's are stored as cookies and have reasonable expiration time, like 1-2 hours, they would be extremely hard for an attacker to get their hands on (just like cookies). Even if a jwt is compromised, things like "linking it" with the ip from where it was generated drastically reduces what the attacker can do with a leaked jwt (and thus not even needing to implement a "blacklist", which again, it's not rocket science).

Hey there @monacoremo, really nice work on this example.

I've been reviewing your work and I've noticed that you use authenticator as the db-anon-role.

If you instead use anonymous, your example will go in line with what we say on http://postgrest.org/en/v6.0/auth.html. Basically, that the authenticator should just be in charge of connecting to the db and switch to other roles, and not even have access to functions.

This would imply some changes on the authenticate function flow, for example you would have to:

-- grant execute on function api.authenticate to authenticator;
++ grant execute on function api.authenticate to anonymous;

(the anonymous role has the ability to authenticate, this is similar to what we say for login in http://postgrest.org/en/v6.0/auth.html)

I think it'll be good to match the docs so we can offer a similar way to do jwt and sessions.

It would be nice to have a CI pipeline that runs the tests automatically. What would be the best way to set this up?

• CircleCI with a NixOS Container?
• Hercules-CI (Nix specific)
• ...