Enhancing Security - Expert Oracle and Java Security - page 313

/
BEGIN
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL (
acl => 'smtp_acl_file.xml',
host => 'smtp.org.com',
lower_port => 25,
upper_port => NULL);
COMMIT;
END;
/
CALL DBMS_JAVA.GRANT_PERMISSION(
'APPSEC',
'java.net.SocketPermission',
' www.org.com:80',
'connect, resolve'
);
Revoke PUBLIC Grant on Sensitive Data Dictionary Views
One of our primary reasons for establishing a separate Oracle instance in order to do application
verification/authorization is that we want to be even more restrictive on what a hacker would be able to
see and do if he gained access to the appver password. Remember, we have only obfuscated the
password; we have not encrypted it.
Besides limiting the number of users with passwords on the new apver instance, we also want to
remove the ability to SELECT on certain by-default PUBLIC views from the Oracle Database Data
Dictionary. In particular, we are going to remove PUBLIC access from the ALL_USERS , ALL_SOURCE,
ALL_TRIGGERS and ALL_VIEWS views. These particular data dictionary views expose accounts and code
that can be leveraged in a computer security attack. Even though for most of these views, the exposure is
only to code that has been granted to the user, we prefer to allow the user to run code without being able
to see the code.
The ALL_USERS view will still need to be accessible by appsec in order to successfully execute
procedures for 2-factor authentication. In Listing 11-51, we will GRANT SELECT on ALL_USERS directly to
the appsec user, not to a role. The appsec user password is expired, so the ALL_USERS view will remain
inaccessible to hackers.
Listing 11-51. Secure Public Data Dictionary Views
GRANT SELECT ON sys.all_users TO appsec;
REVOKE SELECT ON sys.all_users FROM PUBLIC;
REVOKE SELECT ON sys.all_source FROM PUBLIC;
REVOKE SELECT ON sys.all_source_ae FROM PUBLIC;
REVOKE SELECT ON sys.all_triggers FROM PUBLIC;
REVOKE SELECT ON sys.all_views FROM PUBLIC;
REVOKE SELECT ON sys.all_views_ae FROM PUBLIC;