Fortify扫描提示SQL注入风险：改用StringBuilder拼接SQL仍未解决

嗨，我完全懂你现在的困扰——本来想着把字符串拼接从+改成StringBuilder就能搞定Fortify的SQL注入警告，结果还是栽在了同一个问题上。其实核心问题根本不是用不用StringBuilder，而是你还没真正用上PreparedStatement的参数绑定机制，这才是防范SQL注入的关键所在。

你看你当前的代码：不管是用+还是StringBuilder，本质都是把完整的SQL语句拼接好之后再传给connection.prepareStatement()。这种方式和直接拼接字符串没有任何本质区别，Fortify依然会识别出这是动态构造的SQL语句，自然会触发注入风险警告。

要解决这个问题，你得利用PreparedStatement的预编译和参数占位符功能，具体做法是用?作为SQL中的占位符，然后通过statement.setXXX()方法来传入参数，而不是把参数直接拼进SQL里。举个适配你场景的修改示例：

public int prepareSql(String queryType) {
    String baseSql = "Select username, password from loginDetails where ";
    String selectQuery;
    
    // 先确定带占位符的SQL模板
    if ("id".equals(queryType)) { // 这里注意要用equals判断，不是赋值运算符=
        selectQuery = baseSql + "id = ?";
    } else {
        selectQuery = baseSql + "name = ?";
    }

    Connection connection = ***; // 你的连接获取逻辑
    PreparedStatement statement = connection.prepareStatement(selectQuery);
    
    // 根据queryType给占位符设置对应参数
    if ("id".equals(queryType)) {
        statement.setInt(1, 123); // 第1个占位符传入int类型的ID值
    } else {
        statement.setString(1, "test"); // 第1个占位符传入字符串类型的名称
    }

    // 这里执行查询就不会被Fortify标记为注入风险了
    ResultSet resultSet = statement.executeQuery();
    while (resultSet.next()) {
        // 你的结果处理逻辑
    }
    
    // 记得要在finally或者用try-with-resources关闭连接、statement等资源，避免泄漏
    return ...; // 根据你的业务逻辑返回对应值
}

为什么这样就安全了？因为PreparedStatement会先预编译好带有占位符的SQL模板，参数是单独传递给数据库的，数据库会把这些参数当作纯数据处理，不会解析成SQL语句的一部分，从根源上杜绝了SQL注入的可能，Fortify也会识别到这种安全写法，不再触发警告。

另外还要提醒一句：如果queryType是来自用户输入的内容，一定要先做合法性校验（比如只允许"id"和"name"这两个值），防止传入非法值引发其他安全问题。

备注：内容来源于stack exchange，提问作者Karthika