java - 私有(private)查询方式是否会增加SQL注入(inject)攻击风险？

Question

有人指出，使用私有(private)方法来处理单个类完成的所有查询的查询执行会增加 SQL 注入(inject)攻击的风险。

此方法的示例可能如下所示(如下)。我省略了一些细节，以免分散实现过程中的任何人的注意力。

如果您想谈论实现，请随时在评论中留言。安全审查没有评论该方法的内容，主要是它不应该是它自己的方法。

请注意，queryText 是根据 protected 静态最终字符串生成的，其中包含准备好的语句的 SQL 文本。准备好的语句文本中的 ? 是使用PreparedStatement 的setString(或其他设置)方法设置的。在准备好的语句上设置的变量以尽可能强类型的方式进入调用方方法。

queryText 然后被传递给私有(private)方法。

    private ResultSet executeQuery(PreparedStatement stmt) throws SQLException {

    // Declare result set variable
    try{
        try{
            // execute statement and store in variable
        }
        catch(SQLException se){
            // log, close connection, do any special processing, rethrow se
        }

    }
    finally{
                    // This finally block is here to ensure the connection closes if
                    // some special processing (not shown) in the other try generates a runtime exception
        // close connection and statement properly
    }
    // return result set
}

推荐的替代方案是在执行查询的每个方法中基本上内联相同的代码。

我没有将其发布到 security.stackexchange.com，因为我认为它符合特定的安全编程问题。

我想不出为什么将此代码(从私有(private)方法)复制到许多类中会增加任何保护。会吗？

谢谢

Answer 1

拥有一个中央(非重复)位置来执行查询是一个好主意。无论是从代码可维护性还是从安全角度来看。为什么代码可能多次出现问题？这仅意味着您必须多次维护它!

对我来说重要的是(并且通过问题的编辑而改变)，用它执行手工构建的 SQL 字符串应该尽可能困难。

例如，您可以用自定义枚举替换任何 String 参数(您最初拥有该参数，但此后用 PreparedStatement 替换):

public enum SQLQuery {
  QUERY1("SELECT foo FROM BAR", 0),
  QUERY2("SELECT foo from BAR where baz = ?"; 1);

  private final String sql;
  private final int argumentCount;

  private SQLQuery(final String sql, final int argumentCount) {
    this.sql = sql;
    this.argumentCount = argumentCount;
  }

  public String getSQL() {
    return sql;
  }

  public int getArgumentCount() {
    return argumentCount;
  }
}

然后你可以这样编写你的方法:

public ResultSet executeQuery(SQLQuery query, Object... arguments) {
  // implementation left as an exercise for the reader
}

这样您就可以非常确定您(或团队中的其他任何人)不会意外地将自构建字符串传递到您的方法中。

^{如果需要，可以扩展此方法以处理不同的参数类型，但在许多情况下使用 setObject() 效果很好。}

为了提高模块化性，您可以从该枚举中提取一个接口(interface)，并允许多个枚举定义查询(例如，如果您的项目中有单独的模块)。但这有一个缺点，即恶意(或无知)的开发人员可以使用 SQLQuery 的动态非枚举实现将其手动构建的 SQL 字符串放入该方法中。