【问题标题】:Does the Java/Hibernate Criteria Query API Protect Against Injection?Java/Hibernate Criteria Query API 是否可以防止注入?
【发布时间】:2017-09-02 06:17:34
【问题描述】:

这可能是一个愚蠢的问题,但我没有在文档中看到任何明确说明条件查询是参数化的或以其他方式在幕后受到注入保护的内容。

换句话说,像下面这样的谓词是否直接容易受到注入攻击?如果是这样,我该如何解决?环顾文档,我没有看到任何参数化选项或类似的选项。

criteriaBuilder.like(
    root.get("prop"),
    "%"+userInput+"%"
)

【问题讨论】:

  • 为什么要关心它是否参数化?您关心的是是否存在注入漏洞。
  • 当然,很公平。我之所以这么说是因为参数化是首先想到的,它以一种一致的方式来提供体面的注入防御,并且它与 API 的结构保持一致。但你是对的,它们的实现细节与结果没有直接关系,直接询问也没有意义。我会改写我的问题。
  • 我会假设任何 优质 库都不允许 SQL 注入攻击,除非另有说明。但是,请注意这仅适用于 优质 库。 Hibernate 对我来说似乎是一种,但我从未使用过它。
  • Roger 那 - 这也是我的假设,尽管最好在文档中找到他们为我明确勾选框的行。 :)
  • 不一定会记录在案 - 就像他们可能不会记录它不受 shell 注入攻击、Lua 代码注入攻击或 XSS 攻击一样。

标签: java hibernate persistence criteria hibernate-criteria


【解决方案1】:

是的。

使用 Criteria API 与使用参数化 PreparedStatements 相同。唯一需要注意的是不要连接查询字符串,或者如果确实需要,请非常小心。

【讨论】:

    【解决方案2】:

    是的,hibernate 正在对条件使用参数化查询*

    确认这一点的最简单方法是激活 sql 日志记录(将 org.hibernate.SQL 类别设置为 DEBUG),您将看到 hibernate 产生的查询(要获取参数值,请激活日志类别:org .hibernate.type 到 TRACE 级别)。

    *在标准中,您可以手动编写 sql 部分(使用Restrictions.sqlRestriction("..."))。如果你写的 sql 容易被 sql 注入,你的条件查询也会受到它的影响。

    【讨论】:

      猜你喜欢
      • 2013-02-10
      • 2017-12-08
      • 1970-01-01
      • 2013-08-01
      • 2021-10-06
      • 1970-01-01
      • 1970-01-01
      • 2013-02-25
      • 1970-01-01
      相关资源
      最近更新 更多