package org.hsqldb.lib;
public class RCData {
public Connection getConnection(String curDriverIn, String curTrustStoreIn)
throws ClassNotFoundException,
MalformedURLException,
SQLException {
......
try {
urlString = expandSysPropVars(url);
} catch (IllegalArgumentException iae) {
throw new MalformedURLException(iae.toString() + " for URL '"
+ url + "'");
}
String userString = null;
if (username != null) try {
userString = expandSysPropVars(username);
} catch (IllegalArgumentException iae) {
throw new MalformedURLException(iae.toString()
+ " for user name '" + username
+ "'");
}
...
}
}
Sensitive messages (URL and username) are outputted directly and may leak when throwing MalformedURLException.
logger.error(...) may be better than 'throw new MalformedURLException(...)'.
Nothing here is exposed from the database, as the values being reported on are invalid values that haven't even been presented to the database.
There is exposure to the client JVM, but exposure of two things that are already available to the client JVM. Everything done in RCData is client side, so anybody who has access to the JVM gets no more visibility than they already had.
If you are concerned about exposure to outside of the JVM by the exception displaying to stderr, that isn't controlled by RCData but by the client application, for example our SqlTool and DatabaseManager or third party or home-spun apps. RCData doesn't write anything to stderr. The calling application has the full power to catch any Exception thrown within RCData. Whether an app displays the messages from these 2 exceptions to end user is a design decision to be made by weighing security vs. utility. For free-form interactive client apps like DatabaseManager and SqlTool (as for Derby ij, isql, sqlplus), it's pointless to hide successful user name and connection details since even minimal-privilege logins can interactively display that data.
Last edit: Blaine Simpson 2020-11-05
The ticket is not clear, but good answer.