Ron Johnson wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/09/07 10:02, Kenneth Downs wrote:
Karsten Hilbert wrote:
On Fri, Mar 09, 2007 at 08:08:11AM -0500, Kenneth Downs wrote:
First, security is defined directly in terms of tables, it is not
arbitrated by code. The "public" group has SELECT access to the
articles table and the schedules tables, that's it. If a person
figures out how our links work and tries to access the "claims" table
it will simply come up blank (and we get an email).
How ?
Karsten
If a user has not logged in, that is, if they are an anonymous visitor,
the web framework will connect to the database as the default "public"
user. Our system is deny-by-default, so this user cannot actually read
from any table unless specifically granted permission. In the case
being discussed, the public user is given SELECT permission on some
columns of the insurance carriers table, and on the schedules table.
The column-level security is important, as you don't want anybody seeing
the provider id!
If the user figures out our URL scheme, they might try something like
"?gp_page=patients" and say "Wow I'm clever I'm going to look at the
patients table", except that the public user has no privilege on the
table. The db server will throw a permission denied error.
What about an SQL injection bug that allows for increased privileges?
Um, web programming 101 is that you escape quotes on user-supplied inputs. That ends SQL injection.
After that, as stated above, anything the user attempts is executed at his privilege level. For an anonymous user, that's the lowest.
The biggest security limitation we have is actually a weakness in Postgres - the inability to restrict the abilities of a user with CREATUSER rights, they can make somebody who can do anything. For higher security this requires no ability for public registration of accounts. This would be solved if we could restrict a CREATUSER user to only GRANTing to roles they themselves are in.