Re: Security and Web Application Server

In article <35D84AC1.F37BBE0F_at_isa.dknet.dk>, Karsten Weikop <karsten_at_isa.dknet.dk> wrote:

> I'm working on a projekt where we will use Oracle Web Application
> Server. We estimate we will have 100.000+ users.
>
> What is the best solution so set up security in such a system.

This will get you started, but it's probably not complete.

0. Have clear, detailed policies and procedures for your system security that defines who has access to what, and why.

1. Run the OWAS on a separate system to your database, with a firewall between the OWAS and the outside world, and another between it and the database server. *Only* allow HTTP to the OWAS, and *only* allow SQL*Net to the database. On your database server, use PROTOCOL.ORA to refuse SQL*Net connections from anywhere but authorised hosts. (Keep them to a minimum.)
2. Shut off *all* other network services on your web server (inetd, lockd, statd, sendmail, etc.), and all unnecessary network services on your database server. Turn off the admin web listener.
3. Shut off all CGI processing on your web server, except for the OWAS cartridges (and then, only keep the ones that you absolutely need).
4. Assume that your web server will get trashed sooner or later, and keep a full backup on tape or offline disk so that you can rebuild it quickly. Keep no application data on your web server.
5. Monitor both systems carefully -- use something like Tripwire to detect tampering, if it occurs.
6. Closely review all of your web code for security holes. Hire a consultant if you need to.
7. If you're using the PL/SQL cartridge, set up your database objects like this:
8. OWA, HTP and HTF are owned by schema A. This schema has CREATE PROCEDURE privileges only. (i.e., not even CREATE SESSION -- revoke it after you've installed the packages.)
9. The database tables and views, plus the procedures needed to perform database operations, are owned by schema B. This schema also has execute on HTP and HTF, owned by A.
10. Database connections from the OWAS connect as schema user C. This schema only has execute privileges on the procedures needed to perform database operations (owned by B), plus the package OWA (owned by A), plus CREATE SESSION.

> I guess that using Oracle as security manager, will give a lot of
> overhead to the database.
>
> If using Basis or Digest, how do you dynamicly change passwords.

It's better to not use the standard HTTP or database authentification in situations like this. It isn't hard to create your own authentication using PL/SQL; store your usernames and passwords in a table, accessible only through procedures. Pass a randomly-generated session key back to the client in a hidden field (or whatever).

Good luck!

• Phil.