Why java.sql.ResultSet.getString is an Information Leakage vulnerability

Question

Recently I started using LAPSE+ for static code analysis and it kept on pointing java.sql.ResultSet.getString as an Information Leakage. The ResultSet is properly closed after its usage.

LAPSE+ does this only for ResultSet.getString() and ResultSet.getObject(). For example, ResultSet.getDate() is not taken as a vulnerability. This behavior confirms to this OWASP page, which indicates only those two getters in ResultSet as vulnerable.

I'm trying to figure out the reason behind this. Does it have something to do with Strings being immutable?

Though not the exact thing (due to confidentiality reasons), following is a sample code block that I'm concerned about:

ResultSet rs = null;

try {
 dbConnection = dataSource.getConnection();
 prepStmt = dbConnection.prepareStatement("SELECT NAME, DOB FROM CUSTOMERS WHERE ID=?");
 prepStmt.setInt(1, customerId);
 rs = prepStmt.executeQuery();
 //do something

 while (rs.next()) {
  String name = rs.getString(1);
  Date dob = rs.getDate(2);
  //do something
 }
} catch (SQLException e) {
 //do something
} finally {
 if (rs != null) {
  try {
   rs.close();
  } catch (SQLException e) {
   log.error("Database error. Could not close result set  - " + e.getMessage(), e);
  }
 }
}

Answer 1

The reasoning might have been that ResultSet.getString and RestulSet.getObject should return a valid result no matter what the underlying value is for the column you specify. So if there was an SQLi attack and column 1 is usually a string but is now some secret number you'll get still a valid result and thus leak information about that result. Whereas ResultSet.getDate will throw an exception if it can't parse the column as a date so no information would be leaked, other than it's an invalid value.

Answer 2

In addition to jcopenha's answer, perhaps you could try using getString( "column label" ). If the table format changes and the column indexes are offset, if you use the labels (select name as n) then referencing with getString( "n" ) should ensure that you get 'n' back. More to the point, if you use a label convention that differs from table column naming convention the two should never overlap.