5 Security considerations

Based on the previous discussion, there are two main JDBC scenarios to consider for security purposes:

In the case of Java applications, the Java code is "trusted". We also consider trusted applets in this category for security purposes.
In contrast, untrusted Java applets are not permitted access to local files and or network connections to arbitrary hosts.

5.1 JDBC and untrusted applets

JDBC should follow the standard applet security model. Specifically:

JDBC should assume that normal unsigned applets are untrustworthy
JDBC should not allow untrusted applets access to local database data
If a downloaded JDBC Driver registers itself with the JDBC DriverManager, then JDBC should only use that driver to satisfy connection requests from code which has been loaded from the same source as the driver.
An untrusted applet will normally only be allowed to open a database connection back to the server from which it was downloaded
JDBC should avoid making any automatic or implicit use of local credentials when making connections to remote database servers.

If the JDBC Driver level is completely confident that opening a network connection to a database server will imply no authentication or power beyond that which would be obtainable by any random program running on any random internet host, then it may allow an applet to open such a connection. This will be fairly rare, and would require for example, that the database server doesn't use IP addresses as a way of restricting access.

These restrictions for untrusted applets are fairly onerous. But they are consistent with the general applet security model and we can see no good way of relaxing them.

5.2 JDBC and Java applications

For a normal Java application (i.e. all Java code other than untrusted applets) JDBC should happily load drivers from the local classpath and allow the application free access to files, remote servers, etc.

However as with applets, if for some reason an untrusted sun.sql.Driver class is loaded from a remote source, then that Driver should only be used with code loaded from that same source.

5.3 Network security

The security of database requests and data transmission on the network, especially in the Internet case, is also an important consideration for the JDBC user. However, keep in mind that we are defining programming interfaces in this specification, not a network protocol. The network protocols used for database access have generally already been fixed by the DBMS vendor or connectivity vendor. JDBC users should verify that the network protocol provides adequate security for their needs before using a JDBC driver and DBMS server.

If JavaSoft proposes a standard for a published protocol for a DBMS-independent JDBC-Net driver, as described in Section 3, then security considerations will be an important factor in the selection of a protocol.

5.4 Security Responsibilities of Drivers

Because JDBC drivers may be used in a variety of different situations, it is important that driver writers follow certain simple security rules to prevent applets from making illegal database connections.

These rules are unnecessary if a driver is downloaded as an applet, because the standard security manager will prevent an applet driver from making illegal connections. However JDBC driver writers should bear in mind that if their driver is "successful" then users may start installing it on their local disks, in which case it becomes a trusted part of the Java environment, and must make sure it is not abused by visiting applets. We therefore urge all JDB driver writers to follow the basic security rules.

These rules all apply at connection open time. This is the point when the driver and the virtual machine should check that the current caller is really allowed to connect to a given database. After connection open, no additional checks are necessary.

5.4.1 Be very careful about sharing TCP connections

If a JDBC driver attempts to open a TCP connection then the open will be automatically checked by the Java security manager. The security manager will check if there is an applet on the current call stack and if so, will restrict the open to whatever set of machines that applet is allowed to call. So normally a JDBC driver can leave TCP open checks up to the Java virtual machine.

However if a JDBC driver wants to share a single TCP connection among several different database connections then it becomes the driver's responsibility to make sure that each of its callers is really allowed to talk to the target database. For example, if we open a TCP connection to the machine foobah for applet A, this does not mean that we should automatically allow applet B to share that connection. Applet B may have no right whatsoever to access machine foobah.

So before allowing someone to re-use an existing TCP connection the JDBC driver should check with the security manager that the current caller is allowed to connect to that machine. This can be done with the following code fragment:

	SecurityManager security = System.getSecurityManager();

	if (security != null) {

	    security.checkConnect(hostName, portNumber);

The Security.checkConnect method will throw a java.lang.SecurityException if the connection is not permitted.

5.4.2 Check all local file access

If a JDBC driver needs to access any local data on the current machine, then it must ensure that its caller is allowed to open the target files. For example

	SecurityManager security = System.getSecurityManager();

	if (security != null) {

	    security.checkRead(fileName);

The Security.checkRead method will throw a java.lang.SecurityException if the current caller is an applet which is not allowed to access the given file.

As with TCP connections, the driver need only be concerned with these security issues if file resources are shared among multiple calling threads and the driver is running as trusted code.

5.4.3 Assume the worst

Some drivers may use native methods to bridge to lower level database libraries. In these cases it may be difficult to determine what files or network connections will be opened by the lower level libraries.

In these circumstances the driver must make "worst case" security assumptions and deny all database access to downloaded applets unless the driver is completely confident that the intended access is innocuous.

For example a JDBC-ODBC bridge might check the meaning of ODBC data source names and only allow an applet to use those ODBC data source names that reference databases on machines to which the applet is allowed to open connections (see 5.4.1 above). But for some ODBC data source names the driver may be unable to determine the hostname of the target database and must therefore deny downloaded applets access to these data sources.

In order to determine if the current caller is a trusted application or applet (and can therefore be allowed arbitrary database access) the JDBC driver can check to see if the caller is allowed to write an arbitrary file:

	SecurityManager security = System.getSecurityManager();

	if (security != null) {

	    security.checkWrite("foobaz");

Contents | Prev | Next

jdbc@wombat.eng.sun.com or jdbc-odbc@wombat.eng.sun.com