10

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);
  }
 }
}
  • Need more information. The linked OWASP article only indicates that you need to watch out for these methods. Could also use some code to see what you're doing with it. – Mark Buffalo Jan 10 '16 at 5:12
  • Added a sample code block. I'm just trying to understand why even OWASP lists only getString and getObject methods. Thanks – drox Jan 10 '16 at 5:50
  • 8
    I haven't used LAPSE+, but any tool that reports something as vulnerable without telling or explaining why, is a piece of bantha poodoo. – Mark Buffalo Jan 10 '16 at 6:13
  • 1
    I believe it's reporting that simply because those two getters are listed in the mentioned OWASP list. Then the question is why OWASP lists only those two rather than all the resultset getters. – drox Jan 10 '16 at 6:18
  • 4
    FWIW it's important to note that I would be very careful before using LAPSE+ for anything, the last release I can see is 2.8.1 from 2011 and the mailing list shows no activity since 2013 – Rory McCune Jan 10 '16 at 11:48
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.

  • maybe prepared statements are already great for reduction in SQL Injection. Error detection in software technology is a thing & so is error correction in a very minimal data exposure. – Shritam Bhowmick Oct 26 '16 at 6:13
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.