Using the Database To Do Too Much - Implementing Database Security and Auditing - page 217

The risk you face with mod_plsql is twofold: As mentioned, most
stored procedures were not built as services that should be open for access
over the Web and may not have enough validation and exception handling
functions. Exposing them to HTTP-based calls can make your environ-
ment less secure. Secondly, mod_plsql has several security issues that you
should care about:
DAD information is maintained in the $ORACLE_HOME/Apache/mod-
sql/cfg/wdsvr.app file and user/password information is kept in
clear text. You should never keep user information in this file because
it creates too large of an exposure. If you specify no username and
password, the HTTP client will be challenged to provide these.
By default there is no administrator password required for adminis-
tering DADs, and an attacker can go to the following URL and
administer mod_plsql:
http://<host>:<port>/pls/admin_/
There are many procedures in the DBMS_%, UTL_% packages, and
in the SYS schema that may have been granted to PUBLIC because
they were used by other stored procedures. Many of these procedures
allow you to access sensitive information and will be very useful to an
attacker. You must remember to set up your DAD configuration file
to exclude these procedures from Web invocation so that an attacker
is not able to call them from outside the database. This is done using
the exclusion_list parameter in the wdsvr.app config file, for example:
exclusion_list=sys.*,dbms_*,utl_*
Unfortunately, this parameter is not even present in the sample
wdbsvr.app file that comes with the default installation.
CERT vulnerability note VU#193523 shows how an attacker can use
a DAD that does not require the caller to be authenticated before
gaining access to procedures that the developer intended to require
authentication. This is a logical flaw in the mod_plsql design and not
something that you can install a patch for.