Database Reference
In-Depth Information
execute that as SQL code. Recall, you may have to
SET DEFINE OFF
to keep from being prompted for
variable substitution at each
&
symbol in the code.
Authenticate on a Separate Oracle Instance
I'm going to describe something now that reveals the extent to which we might want to pursue security.
What if we segregated the application verification tasks from the actual application data? What security
would that buy us? The primary benefits we will achieve are the following:
•
Fewer accounts with passwords, so fewer accounts to attack
•
Reduced ancillary functions (fewer optional database programs), so reduced
vulnerabilities
Ability to revoke some
PUBLIC
access to particularly revealing data dictionary views
without hampering database development
•
•
A first database hurdle for hackers to overcome before sensitive data in the second
database can be pursued by attack
In this section, we will create a new database instance, perhaps on the same server. This instance
will have sufficient privileges to accomplish application verification, but no more. In order to ensure
that, we will not create the privileged roles that we have discussed,
secadm_role
and
app_sec_role
;
rather, we will do all our configuration steps as the
SYS
user.
Caution
If you do not intend to create an additional database instance for application verification, then do not
issue any of the commands in this section. You can skip down to
Test Enhanced Security
; however, to learn about
creating and hardening an Oracle database instance and about database links, read through this section in any
case.
What about our application verification,
appver
user password? Is it still susceptible to snooping?
Well, it isn't encrypted, and it could be recovered by anyone diligent enough to reconstruct our
obfuscated
OJSCode
class. So the question we need to ask is what is our security exposure from having
that password revealed.
We might pat ourselves on the back and say that we've got it covered with our login trigger,
t_screen_appver_access
, on the
appver
schema that calls the
p_appver_logon
stored procedure. And we
might smirk and scoff at those who think they can get by the SSO proxy requirements, and down the
road our two-factor authentication, encryption key exchange, and application verification process.
However, in the back of our minds, we realize that a hacker having a password to an account on a
production Oracle database must be a bad thing. And the back of our minds would be correct. Even if
there is nothing else that the account has access to, there is still
PUBLIC
data, and that data can be
revealing. From standard
PUBLIC
access, a hacker can learn all the users of the database, setting him up
to conduct a social engineering attack. The hacker can also see all the code of any procedures and Java
that is granted to
PUBLIC
, and he can see the logic that is contained in triggers and views.
PUBLIC
grants
provide an entrée into the database for every user account.
