Блог

У меня есть следующий метод, который использует a NamedParameterJdbcTemplate для выполнения SQL-запроса при весенней загрузке:

 @Service class MyRepository(  val jdbcTemplate: NamedParameterJdbcTemplate ) {  fun loadData(myKey: Listlt;Intgt;): Listlt;MyRowgt; {   return jdbcTemplate.query(  """  select  io.KEY as itemKey,  art.ARTICLE_NR as articleNumber,  art.PRICE as price,   concat(  concat(  concat(art.BEST_B, BEST_A),   lpad(BEST_B, 2, '0')),   lpad(BEST_A, 2, '0')) as group  from  BUY.OPTION io  INNER JOIN BUYING.ART art ON (to_char(art.id) = io.keyb)  where  io.KEY IN (:MYKEY)  """.trimIndent(),  parameters  ) { rs, rowNum -gt;  MyRow(  itemOption = ItemOption(rs.getString("ITEMOPTION")),  articleNumber = rs.getString("ARTICLENUMBER"),  price = rs.getBigDecimal("PRICE")  group = rs.getString("GROUP")  )  }  } }  

Этот метод уже защищен от внедрения SQL, поскольку он использует NamedParameterJdbcTemplate? Или для этого мне нужно сделать несколько дополнительных шагов?

При использовании параметров в a NamedParameterJdbcTemplate будет использоваться подготовленная инструкция JDBC с параметрами, которая в целом защитит вас от внедрения SQL.

Я говорю «в целом», потому что фактическая защита зависит от реализации конкретного используемого драйвера JDBC. Основные драйверы JDBC будут — за исключением любых ошибок — защищать вас от внедрения SQL, поскольку они либо разделяют операторы и значения параметров (оператор готовится с заполнителями параметров, и при выполнении отправляются только значения), либо иным образом правильно экранируют данные при создании фактического запроса (т. Е. Поведение по умолчанию в драйвере MySQL Connector/J). Однако ничто не мешает кому-то написать наивный драйвер JDBC, который будет использовать интерполяцию строк для создания запроса, фактически не предотвращая внедрение SQL.