JDBC™ and security

Sniffing JDBC™ network traffic is one possibility for intruders to compromise database applications. This requires physical access to either of:

Figure 879. Sniffing a JDBC™ connection by an intruder.

• 
• 
• 

‹›

We demonstrate a possible attack by analyzing the network traffic between our application shown in Figure 865, “JDBC™ backed data insert ” and the Mysql database server. Prior to starting the application we set up Wireshark for filtered capturing:

Figure 880. Setting up Wireshark

Database server and JDBC™ client on same machine. Connecting to the loopback (lo) interface only. (Sufficient since client connects to localhost) Capture packets of type TCP having port number 3306.

Figure 881. Capturing results

[...
5.5.24-0ubuntu0.12.04.1.%...X*e?I1ZQ...................e,F[yoA5$T[N.mysql_native_password.
 A...........!.......................hdmuser ❶......U.>S.%..~h...!.xhdm............j..../*

 ... INSERT INTO Person VALUES('Jim', 'jim@foo.org') ❷6...
  .&.#23000Duplicate entry 'jim@foo.org' for key 'email' ❸

❶	username initiating database connection.
❷	INSERT(...) statement.
❸	Resulting error message sent back to the client.

Password?

Figure 882. Mysql™ security

What about the missing password?

Making MySQL Secure Against Attackers:

When you connect to a MySQL server, you should use a password.

The password is not transmitted in clear text over the connection.

So regarding our (current) Mysql implementation the impact of this attack type is somewhat limited but still severe: All data being transmitted between client and server may be disclosed. This typically comprises sensible data as well. Possible solutions:

Figure 883. Mysql™ security

• Data exchange client to server nearly fully disclosed.

• Mysql mitigates the attack type's severity

• Possible solutions:

  • Encrypted tunnel between client and server: like e.g. ssh port forwarding or VPN.

  • Use JDBC™ driver supporting TLS.

• Irrelevant e.g. within DMZ.