Re: HIPPA (was Re: Anyone know ...)

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.