Subject | Re: [firebird-support] Users can create anything?!? |
---|---|
Author | Geoff Worboys |
Post date | 2005-05-25T01:26:38Z |
Hi Richard,
the ability for users to create objects, is supposed to be a
"feature". Of course you and I know that it is really a hole
in security to any site that cant trust their users to behave
themselves (and who might know how to install their own copy
of isql or other utility to directly manipulate the db).
There are other holes that need patching. eg: Not only can
a user with direct access create new objects, they can also
change the value of generators - the severity of which will
depend on your particular implementation.
I use an less than perfect solution to these in my systems...
When the a non-admin user logs on to my application their
password is not used directly. Instead it is processed by
a hash function, the result of which is turned into a string
and that is provided as the password.
Hence the user does not actually know their password to the
FB server, and so cannot access the database through any other
application.
There are some downsides...
It is only "obscurity". If someone decodes the executable
they could learn the hash function used, and so be able to
work out their real password. (It also means that I cannot
open-source the code that I use to do this.)
It means that the application must provide its own user
management and password change facilities using the FB API,
in order to have the passwords for non-admin users configured
correctly.
The application must not provide direct DDL scripting features
to the users - or at least not to non-admin users.
It is not perfect, but has been adequate for my purposes.
--
Geoff Worboys
Telesis Computing
> I've just discovered that any user who can log into the...
> server can create any table they want, and presumably
> other objects.
> Please somebody tell me I'm mistaken!No, you are not mistaken. I think the ownership stuff, and
the ability for users to create objects, is supposed to be a
"feature". Of course you and I know that it is really a hole
in security to any site that cant trust their users to behave
themselves (and who might know how to install their own copy
of isql or other utility to directly manipulate the db).
There are other holes that need patching. eg: Not only can
a user with direct access create new objects, they can also
change the value of generators - the severity of which will
depend on your particular implementation.
I use an less than perfect solution to these in my systems...
When the a non-admin user logs on to my application their
password is not used directly. Instead it is processed by
a hash function, the result of which is turned into a string
and that is provided as the password.
Hence the user does not actually know their password to the
FB server, and so cannot access the database through any other
application.
There are some downsides...
It is only "obscurity". If someone decodes the executable
they could learn the hash function used, and so be able to
work out their real password. (It also means that I cannot
open-source the code that I use to do this.)
It means that the application must provide its own user
management and password change facilities using the FB API,
in order to have the passwords for non-admin users configured
correctly.
The application must not provide direct DDL scripting features
to the users - or at least not to non-admin users.
It is not perfect, but has been adequate for my purposes.
--
Geoff Worboys
Telesis Computing