||Oracle Tips by Burleson
Chapter 4 General Oracle Security
not by the user. If, at some point in the
future, the code for processed is changed from P to, say, R, the
users don't have to know about it. The program logic is the only
place it has to be changed.
The third, but the most important one is
By making the table hidden from the applications, we
keep the structure of the table hidden from most users. Since the
users are not given any privilege to update the table data directly,
a malicious attacker cannot update the table directly, he or she has
to use the procedure. Inside the procedure, we can place various
types of checks to ensure that the calling of the procedure is
genuine. By retaining a single point of control for the table
changes, we achieve some degree of control on the changes. In most
cases, this is desirable to enforce a security policy.
This is one model of security for the data.
However, we will unearth some potential problems and issues with
this approach later.
This approach is very useful in the case of
procedures that are frequently called to validate something or do
something repeatedly. For instance, a procedure can be constructed
to authenticate users of an application, not the database. A typical
approach is to create a table to hold the user ids and passwords.
The application connects using a generic id, reads the table for the
password of the user, and matches it with the one supplied by the
However, the system is fraught with large
security holes. Anyone can select the password table and read the
password of another user. It's not acceptable in the security model
we propose. Here is another approach.
The above text is
an excerpt from:
Oracle Privacy Security Auditing
Final Word on Oracle Security
This is the only authoritative
book on Oracle Security, Oracle Privacy, and Oracle Auditing written
by two of the world’s leading Oracle Security experts.
This indispensable book is only
and has an
immediate download of working security scripts: