Re: Security problem

Philip Chee <philip_at_aleytys.pc.my> wrote in message news:949761728.5090snx_at_aleytys.pc.my...
> In article <uuoPhd8b$GA.363_at_net025s> uw.naam_at_hetnet.nl writes:
> >Scott Kronheim heeft geschreven in bericht
<389B1650.3AFAD0B3_at_synertechsystems.com>...
>
> >>The privileges assigned to a non-default role are not utilized by a
> >>user's session until the SET ROLE command is issued. Therefore, when a
> >>user logs into the database using anything other than your application,
> >>they won't have privileges to do anything with your application
> >>objects. Also, the SET ROLE command has a session-level scope, so when
> >>your application disconnects from the database, the privileges
disappear.
>
> >What Scott Kornheim is suggesting is certainly a way to enhance your
> >application's security.
>
> >This isn't water tight though: if your end user can use client software
that
> >can issue the SET ROLE command, there is nothing at the server side that
> >will stop this, and then the user will have all the privileges of the
role.
>
> You could use password protected ROLES and encrypt the hardcoded password
> string in your application code to prevent the user from using a strings
> type utility to dump ASCII strings from your binaries.

Even with encrypted passwords, user can run any of SQL monitorning utilities to detect all Your secure passwords, codes and role-enabling statements. I don't know the way to avoid this. Therefore I suggest never use any kind of application-level restrictions. All securuty measures should be always perfomed by standard Oracle ways. As far as I know, Oracle doesn't allow to resrtict access by the applications.

--
Is There A God Or Any Kind Of Justice Under The Sky... (Queen'91)

Igor V. Podolsky (igoryok_at_soft-review.kiev.ua) Received on Mon Feb 07 2000 - 06:30:28 CST