Database Reference
In-Depth Information
GLdGjZoM6cJZs4nHbLQMRgmOh9ZTnOnU0fQMG0vDHhtBL0CZSmx1R0SWpFQ20Iui96EL3CD4
...
1atpfb/f+oVZAZkY78T0YBdSmyOSgifZtm0IiEdc5rh/Lbn5pmTzHV8=
/
Notice the first line of the wrapped procedure is a
CREATE OR REPLACE
statement. We can copy and
paste this code to any SQL editor, like SQL*Plus, and create the Oracle structure in the database.
I know there is a lot going on, so let me reiterate our goal. In wrapping these functions, our intent is
to keep folks, whether hackers or just snoopers, from knowing how we encrypted the list of connection
strings, and from being able to independently decrypt the strings and read them.
Changes to setDecryptConns()/getCryptConns()
In the middle of the
setDecryptConns()
method that runs as a Java stored procedure, we take the list of
connection strings that we are about to store in Oracle database, and we pass them to the
f_mask
function. Listing 11-23 shows this. The encrypted bytes that are returned from
f_mask
are then stored in
the database.
Listing 11-23.
Call to Encrypt Connection Strings for Storage
stmt = ( OracleCallableStatement )conn.prepareCall(
"{? = call appsec.
f_mask
(?,?,?)}" );
stmt.registerOutParameter( 1, OracleTypes.RAW );
stmt.setBytes( 2,
connsHashBytes
);
stmt.setString( 3, className );
stmt.setString( 4, classVersion );
stmt.executeUpdate();
connsHashBytes = stmt.getBytes
(1);
Note
This code can be found in
Chapter11/orajavsec/OracleJavaSecure.java.
We also modify the
getCryptConns()
method to decrypt the list of connection strings before we
return them to the client application. This is shown in Listing 11-24.
Listing 11-24.
Call to Decrypt Connection Strings from Storage
bA = stmt.getBytes
(4);
stmt = ( OracleCallableStatement )conn.prepareCall(
"{? = call appsec.f_unmask(?,?,?)}" );
stmt.registerOutParameter( 1, OracleTypes.RAW );
stmt.setBytes( 2,
bA
);
stmt.setString( 3, className );
stmt.setString( 4, classVersion );
stmt.executeUpdate();
oins = new ObjectInputStream( new ByteArrayInputStream(
